Re: Non 386 testers REALLY NEEDED
Peter Wemm wrote: The following files: src/gnu/usr.bin/cc/cc_tools/auto-host.h src/gnu/usr.bin/cc/cc_tools/freebsd-native.h .. are vaguely based on stuff that configure generated and are hand tweaked to deal with the *freebsd* environment (eg: whether printf supports %p etc), rather than compiler configuration. The compiler and language configuration is done at runtime in the bmake files. eg: Ports does the same thing: hand tweaks stuff instead of pushing the patches back to the projects that originated it. It's far, far better that the Makefile runs the autoconf/automake/configure/etc. on behalf of the contrib code, with no hand-tweaked files dragged in after the config has already been run. In theory, this code, and the FreeBSD hierarchy that's used to build it, should compile successfully on any platform, FreeBSD or not. When I make something run on FreeBSD (e.g. OpenSLP, OpenLDAP, MySQL, ACAP, Cyrus, etc.), I always send the changes back to the originating project, rather than putting them in a patch file, or an extra file derived from a post-configure. To get back on track, the gcj stuff will be really hard to deal with, unless it can be dealt with natively. In other words, anything that has to be done in a FreeBSD specific way really thwarts this goal. If these (and other contrib build files elsewhere) are not hgenerated correctly by the configure/automake/autoconf/etc. process, then it's the process, not the files, that need to be corrected. Personally, I have great dislike for the tools used to create nominal platform independence; the imake/xmkmf stuff was really much better thought out for platfirm independence. But if we're stuck with the GNU munging, then we are stuck with it, and it's better to embrace it than it is to deny it by checking in hacked code to work around an unwillingness to correct it. Wasn't someone recently saying the same thing about the stdup()'s in the YP code to make it not bitch about the discarding of the const qualifier? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Max Khon wrote:
please calm down. seems that you have never installed gcc from ports.
gcc 2.95 from ports is installed as gcc295/g++295
and correctly gets its bits from /usr/local/lib/gcc-lib/xxx,
gcc 3.0x from ports is named gcc30/g++30 and so on.
There is no PATH issue. Switching between compilers is as easy as
setting correct CC/CXX environment/Makefile variables.
And hacking the Makefile a lot to specify command line
arguments in the compiler program definition itself, so
that the /usr/include/g++ files that came with the old
compiler are not used for make release and other types
of make targets where DESTDIR is fairly mandatory.
See /usr/src/share/mk/bsd.prog.mk, ~line 14:
.if defined(DESTDIR) !defined(BOOTSTRAPPING)
CFLAGS+= -I${DESTDIR}/usr/include
CXXINCLUDES+= -I${DESTDIR}/usr/include/g++
.endif
See also /usr/src/share/mk/bsd.lib.mk, ~line 40.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
Garance A Drosihn wrote (2002/02/06): Anything else I should check? I realize there's about a million differences between the two branches, and there might also be something about my machine's setup which is a major culprit here. I'm just looking for a basic idea of what other people have been seeing for performance when they run current. There is another common source of confusion: If anybody has IDE disks, write-caching is enabled by default in -stable, but disabled in -current. -- Rudolf Cejka cejkar at fit.vutbr.cz http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
The bad ivar request (4) message does *not* come from the ATA driver, you must have something else that is ruining your day... Does it boot if you take out the promise board ? I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mergemaster niggle
On Wed, Feb 06, 2002 at 02:13:08PM -0600, David W. Chapman Jr. wrote: What I think mergemaster should do is compere the file with the original checked out one it claims to be and if it's the same, it should just update silently.. i.e. if the user didn't change anything in th old one he's unlikely to want to change anything in the new one (maybe a datafile that contains cksum outputs for each version of each file) I think part of the problem(from what I'm hearing on irc), someone made a lot of commits to etc which weren't supposed to happen, but I cannot confirm all the facts at the moment. *Raises hand.* I had a botched cvs(1) command line run away and did some forced commits on /etc files. You would only have seen it if you updated over a few hour stretch; the Repo Lords fixed it. You lucked out and must have updated during the window. ;) Note that if you look at your diff, the revision number went _backwards._ -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: The bad ivar request (4) message does *not*?come from the ATA driver, you must have something else that is ruining your day... Does it boot if you take out the promise board ? I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/dev/rtc not configured message when starting VMWare2 on -current
Hi, since many weeks I get /dev/rtc: device not configured in -current when I start VMWare2. The VMWare2 port works fine otherwise. Yes, rtc-2001.09.16.1 is installed, and the module is loaded during startup. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/dev/rtc not configured message when starting VMWare2 on -current
Hi, since many weeks I get /dev/rtc: device not configured in -current when I start VMWare2. The VMWare2 port works fine otherwise. Yes, rtc-2001.09.16.1 is installed, and the module is loaded during startup. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg Here's the box: Asus CUV4X-D mainboard, VIA 694X, dual-capable 2x P3-933, 768MB PC133 RAM in 3 DIMM(s) Two IBM IC35L 60.1GB disks on first IDE Pioneer DVD-A05SZ on second IDE Two IBM IC35L 60.1GB on Promise Fasttrak TX2 (PDC20268/70) in RAID0 How do I dump the dmesg when it crashs into the debugger? /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PCCARD not working on HP Omnibook 6100
Hi, I can't get my PCMCIA card to work on my HP Omnibook 6100. -current is from Feb 6. During boot I get: Feb 7 10:14:04 hunter kernel: pcic0: TI PCI-1420 PCI-CardBus Bridge irq 5 at device 5.0 on pci2 Feb 7 10:14:04 hunter kernel: pcic0: PCI Memory allocated: 0xd020 Feb 7 10:14:04 hunter kernel: pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] Feb 7 10:14:04 hunter kernel: pccard0: PC Card bus (classic) on pcic0 Feb 7 10:14:04 hunter kernel: pci_cfgintr_linked: linked (63) to hard-routed irq 10 Feb 7 10:14:04 hunter kernel: pci_cfgintr: 0:30 INTD routed to irq 10 Feb 7 10:14:04 hunter kernel: pcib2: routed slot 5 INTB to irq 10 Feb 7 10:14:04 hunter kernel: pcic1: TI PCI-1420 PCI-CardBus Bridge irq 10 at device 5.1 on pci2 Feb 7 10:14:04 hunter kernel: pcic1: PCI Memory allocated: 0xd0201000 Feb 7 10:14:04 hunter kernel: pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] Feb 7 10:14:04 hunter kernel: pccard1: PC Card bus (classic) on pcic1 Feb 7 10:14:04 hunter kernel: fxp0: Intel Pro/100 Ethernet port 0x3440-0x347f mem 0xd020-0xd0200fff irq 10 at device 8.0 on pci2 Feb 7 10:14:04 hunter kernel: fxp0: Ethernet address 00:c0:9f:05:88:52 Feb 7 10:14:05 hunter kernel: inphy0: i82562EM 10/100 media interface on miibus0 Feb 7 10:14:05 hunter kernel: inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Feb 7 10:14:05 hunter kernel: isab0: PCI-ISA bridge at device 31.0 on pci0 Feb 7 10:14:05 hunter kernel: isa0: ISA bus on isab0 Feb 7 10:14:05 hunter kernel: atapci0: Intel ICH3 ATA100 controller port 0x1820-0x182f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xd000-0xd3ff at device 31.1 on pci0 Feb 7 10:14:05 hunter kernel: ata0: at 0x1f0 irq 14 on atapci0 Feb 7 10:14:05 hunter kernel: ata1: at 0x170 irq 15 on atapci0 Feb 7 10:14:05 hunter kernel: pci0: serial bus, SMBus at device 31.3 (no driver attached) Feb 7 10:14:05 hunter kernel: ata: ata0 already exists; skipping it Feb 7 10:14:05 hunter kernel: ata: ata1 already exists; skipping it Feb 7 10:14:05 hunter kernel: pcic: pcic0 already exists; skipping it Feb 7 10:14:05 hunter kernel: pcic: pcic1 already exists; skipping it and later when pccardd starts: Feb 7 10:16:35 hunter kernel: pcib2: device pccard0 requested unsupported memory range 0xd-0xd (decoding 0xd020-0xd02f, 0xf000-0xf00f) Feb 7 10:16:35 hunter kernel: pcib2: device pccard0 requested unsupported memory range 0xd4000-0xd4000 (decoding 0xd020-0xd02f, 0xf000-0xf00f) Feb 7 10:16:35 hunter pccardd[480]: ioctl (PIOCRWMEM): Invalid argument Feb 7 10:16:40 hunter pccardd[480]: No card in database for (null)((null)) Feb 7 10:16:40 hunter pccardd[480]: pccardd started Also, only the upper PCMCIA slots seems to be active. I get a beep and some messages when I remove/insert a card in the upper slot, but with the lower slot nothing happens at all. My card is a Psion Dacom Gold Card modem. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg Here's the box: Asus CUV4X-D mainboard, VIA 694X, dual-capable 2x P3-933, 768MB PC133 RAM in 3 DIMM(s) Two IBM IC35L 60.1GB disks on first IDE Pioneer DVD-A05SZ on second IDE Two IBM IC35L 60.1GB on Promise Fasttrak TX2 (PDC20268/70) in RAID0 How do I dump the dmesg when it crashs into the debugger? With a current kernel from before you found it failed ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
On Thu, 2002-02-07 at 08:01, Julian Elischer wrote: for the set of patches at: http://www.freebsd.org/~julian/adiff these patches SHOULD NOT EFFECT your system except to do some slight re-aranging of stuff in the kernel. THe aim is to get this committed to 'clarify' the upcoming KSE commit in http://www.freebsd.org/~julian/thediff which includes adiff as a subset. when adiff is committed thediff will become a lot easier for people to read and check. I'd like to get adiff in relatively soon. This causes some breakage in PowerPC but I'm working on it. Go ahead and commit and I'll fix PowerPC up after. -- Benno Rice [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Support for atapi cdrw as scsi in -current?
hi, there! On Tue, Feb 05, 2002 at 08:14:22PM +0100, Thomas Quinot wrote: Is there a place where I can find this updated patch which will work for me in the current -current? Thanks. I put up updated patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ For -CURRENT, you should be using the latest one (of today) which fixes a silly line inversion. I'd be very interested in success/failuire reports on this patch, especially with ATAPI tape or floppy drives. I successfully recorded data cd using cdrecord on NEC NR-7700A IDE CD-RW. dmesg follows Copyright (c) 1992-2002 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 4.5-STABLE #0: Thu Feb 7 04:49:06 NS 2002 [EMAIL PROTECTED]:/usr/obj/usr/fbsd/RELENG_4/src/sys/husky Timecounter i8254 frequency 1193182 Hz CPU: AMD-K7(tm) Processor (503.53-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x612 Stepping = 2 Features=0x81f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX AMD Features=0xc040AMIE,DSP,3DNow! real memory = 268369920 (262080K bytes) config enable apm0 config quit avail memory = 256040960 (250040K bytes) Preloaded elf kernel kernel at 0xc04af000. Preloaded userconfig_script /boot/kernel.conf at 0xc04af09c. Preloaded elf module if_ppp.ko at 0xc04af0ec. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 7 entries at 0xc00f82b0 apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: AMD-751 host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: AMD-751 PCI-PCI (1x/2x AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia Riva Ultra Vanta TNT2 graphics accelerator at 5.0 irq 11 isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xffa0-0xffaf at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 12 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 uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 12 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 chip1: VIA 82C686 ACPI interface at device 4.4 on pci0 pci0: unknown card (vendor=0x1274, dev=0x1371) at 13.0 irq 11 ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xc400-0xc41f irq 5 at device 14.0 on pci0 ed0: address 00:00:01:00:fb:08, type NE2000 (16 bit) sym0: 810a port 0xd800-0xd8ff mem 0xef00-0xefff irq 10 at device 15.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking orm0: Option ROMs at iomem 0xc-0xc,0xd-0xd3fff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging disabled ad0: 9671MB IBM-DTTA-351010 [19650/16/63] at ata0-master UDMA33 acd0: CD-RW _NEC NR-7700A at ata1-master using PIO4 (noperiph:atapi1:0:-1:-1): Registered SIM for ata1 Waiting 15 seconds for SCSI devices to settle atapicam1m: read data overrun 96/95 Mounting root from ufs:/dev/ad0s2a cd1 at atapi1 bus 0 target 0 lun 0 cd1: _NEC NR-7700A 1.01 Removable CD-ROM SCSI-0 device cd1: 3.300MB/s transfers cd1: cd present [347816 x 2048 byte records] cd0 at sym0 bus 0 target 6 lun 0 cd0: SONY CD-R CDU948S 1.0e Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: cd present [327225 x 2048 byte records] pcm0: AudioPCI ES1373-8 port 0xc800-0xc83f irq 11 at device 13.0 on pci0 /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Support for atapi cdrw as scsi in -current?
hi, there! On Thu, Feb 07, 2002 at 12:38:08PM +0100, Søren Schmidt wrote: I put up updated patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ For -CURRENT, you should be using the latest one (of today) which fixes a silly line inversion. I'd be very interested in success/failuire reports on this patch, especially with ATAPI tape or floppy drives. I successfully recorded data cd using cdrecord on NEC NR-7700A IDE CD-RW. dmesg follows Doesn't burncd work for you on -current ? I tried burncd in -stable. it works for me. but with ATAPI CAM stuff you get access to a whole bunch of neat cd recording and cd ripping tools (e.g. cdrdao) I haven't tried DAO with burncd in -current (I haven't tried DAO with ATAPI CAM stuff too but I'll try to find spare time this week to test it, I do not even know if cdrdao supports my drive). /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Max size of a process in FreeBSD.
Doug White [EMAIL PROTECTED] writes: It's limited to MAXDSIZ (max data size). Not quite - the size of the data segment is limited to the value of 'limits -d', which starts out at DFLDSIZ and cannot be larger than MAXDSIZ. Likewise, the size of the stack is limited to the value of 'limits -s', which cannot be larger that MAXSSIZ. I don't think there's a limit on text size (other than total address space minus kernel address space), but a very large text segment will obviously limit the size of the data and stack segments. You can raise this up to 2GB or so, but you will eventually hit the KVM boundary. I don't recall what the KVM limit is right now, I thought it was 2GB but I think it was reduced recently ... The kernel address space used to be 256 MB in 3.x, but was bumped to 1 GB before 4.0-RELEASE. See FAQ list entry 17.15. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems setting up TCP/IP in 5.0-CURRENT...
Hello,
I have been using -current for a few weeks now after converting from
linux and then finding that a lot of things I wanted to do only work in
-current and not -stable. However the only thing which I can not get to
work exactly as it did in Linux on -current are my TCP/IP settings. I
have two ethernet cards, one which I use for outbound (default net)
traffic and its responses, and one card which I use for inbound port
forwards from my hardware router as well as inbound/outbound for my
192.168.1.0 net. I have been able to get this to work perfectly, but
only in 4.5-RELEASE (well actually in -stable, ie. 4.4-RELEASE,
4.5-RC{1,2,3}, and 4.5-RELEASE). Here is a small session which shows a
successful setup under -stable:
#ifconfig -a
xl0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
ether 00:01:02:3b:2b:c2
media: Ethernet autoselect (100baseTX full-duplex)
status: active
xl1: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
ether 00:01:02:3b:2b:77
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
sl0: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552
#ifconfig xl0 192.168.1.2 netmask 255.255.255.0
#ifconfig xl1 192.168.1.3 netmask 255.255.255.0
#ifconfig -a
xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255
inet6 fe80::201:2ff:fe3b:2bc2%xl0 prefixlen 64 scopeid 0x1
ether 00:01:02:3b:2b:c2
media: Ethernet autoselect (100baseTX full-duplex)
status: active
xl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255
inet6 fe80::201:2ff:fe3b:2b77%xl1 prefixlen 64 scopeid 0x2
ether 00:01:02:3b:2b:77
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
sl0: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552
#route delete -net 192.168.1.0
#route add -net default 192.168.1.1
#route add -net 192.168.1.0 -interface 192.168.1.3
#netstat -r
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default192.168.1.1UGSc0 21xl0
192.168.1 link#2 UCSc40xl1
Internet6:
DestinationGatewayFlags Netif Expire
localhost localhost UH lo0
fe80::%xl0 link#1 UC xl0
fe80::201:2ff:fe3b 0:1:2:3b:2b:c2 UHL lo0
fe80::%xl1 link#2 UC xl1
fe80::201:2ff:fe3b 0:1:2:3b:2b:77 UHL lo0
fe80::%lo0 fe80::1%lo0Uc lo0
fe80::1%lo0link#3 UHL lo0
ff01:: localhost U lo0
ff02::%xl0 link#1 UC xl0
ff02::%xl1 link#2 UC xl1
ff02::%lo0 localhost UC lo0
This shows no problems at all and works whether I use the routing daemon
or use static routes at boot up, however -current will not allow me to
do the same thing that I have done above, instead I get the following:
bash-2.05a# ifconfig -a
xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255
inet6 fe80::201:2ff:fe3b:2bc2%xl0 prefixlen 64 scopeid 0x1
ether 00:01:02:3b:2b:c2
media: Ethernet autoselect (100baseTX full-duplex)
status: active
xl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=3rxcsum,txcsum
inet 192.168.1.3 netmask 0x broadcast 192.168.1.3
inet6 fe80::201:2ff:fe3b:2b77%xl1 prefixlen 64 scopeid 0x2
ether 00:01:02:3b:2b:77
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
ppp0: flags=8010POINTOPOINT,MULTICAST mtu 1500
bash-2.05a# ifconfig xl1 192.168.1.3 netmask 255.255.255.0
ifconfig: ioctl (SIOCAIFADDR): File exists
The only thing which I can think of is that either a) it is a userland
change in -current, or b) I was only ever running the GENERIC kernel for
4.5-RELEASE and never recompiled my kernel until I was compiling with
-current source so maybe it is some option in the GENERIC config file
for the -current source. If it is b) could someone please tell
Re: ThinkPad X22 PC-Card slot problem
From: M. Warner Losh [EMAIL PROTECTED]
Date: Wed, 06 Feb 2002 19:33:32 -0700 (MST)
Hmmm. This looks ugly. :-( I can't boot with acpi enabled on my Dell
Inspiron 8000. I can boot with apm enabled. There are issues with
routing interrupts accross PCI PCI bridges at the moment when the
slots on the other side of the bridge are in the PIR table.
It turned out that this was not a intterupt routing problem. By
disabling the memory/port range checks in sys/dev/pci/pci_pci.c solved
the problem (below is the patch). pci_pci.c claims that both the
memory adderss for pcic and the PC-Cards are not supported but I could
use the addresses.
// Noriaki Mitsunga //
Index: pci_pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v
retrieving revision 1.6
diff -u -r1.6 pci_pci.c
--- pci_pci.c 15 Jan 2002 06:46:59 - 1.6
+++ pci_pci.c 7 Feb 2002 09:55:44 -
@@ -282,15 +282,18 @@
*/
switch (type) {
case SYS_RES_IOPORT:
+#if 0
if (start sc-iobase)
start = sc-iobase;
if (end sc-iolimit start end)
end = sc-iolimit;
+#endif
if ((start sc-iobase) || (end sc-iolimit)) {
device_printf(dev, device %s%d requested unsupported I/O range
0x%lx-0x%lx
(decoding 0x%x-0x%x)\n,
device_get_name(child), device_get_unit(child), start,
end,
sc-iobase, sc-iolimit);
+#define PCI_ALLOW_UNSUPPORTED_IO_RANGE
#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE
return(NULL);
#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Problems setting up TCP/IP in 5.0-CURRENT...
Jordan Breeding wrote: #ifconfig xl0 192.168.1.2 netmask 255.255.255.0 #ifconfig xl1 192.168.1.3 netmask 255.255.255.0 This is bogus. You are telling the machine that the 192.168.1 net exists on both xl0 and xl1. It exists on only one or the other of them. To which interface do you expect it to send a packet destined for 192.168.1.7? #route delete -net 192.168.1.0 #route add -net default 192.168.1.1 #route add -net 192.168.1.0 -interface 192.168.1.3 #netstat -r This is still pretty bogus. The 192.168.1.0 route is before the other one, or it doesn't know how to frind the gateway 192.168.1.1, since it doesn't know which interface to write to. This shows no problems at all and works whether I use the routing daemon or use static routes at boot up, however -current will not allow me to do the same thing that I have done above, instead I get the following: [ ... ] bash-2.05a# ifconfig xl1 192.168.1.3 netmask 255.255.255.0 ifconfig: ioctl (SIOCAIFADDR): File exists The only thing which I can think of is that either a) it is a userland change in -current, or b) I was only ever running the GENERIC kernel for 4.5-RELEASE and never recompiled my kernel until I was compiling with -current source so maybe it is some option in the GENERIC config file for the -current source. If it is b) could someone please tell me which option is causing this so that I may turn it back off. I would really like to try and get this working exactly as I have in Linux, Solaris, FreeBSD 4.5-RELEASE. Thanks for any help. Change the netmask to 255.255.255.255 to tell it that it is a point-to-point link. If you want to build a bridge, then you need to turn on ip forwarding (net.inet.ip.forwarding=1). Really, you need to think through your network setup a bit more; each interface needs to be on its own network, so if you mask off the top parts using the netmask, no two interfaces are equal. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current.freebsd.org down?
Hi, I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? I've been unable to log in for almost an hour, the ftp daemon is up, it just doesn't allow me in and I was about to load -CURRENT on my laptop. Any idea? Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org down?
On Thu, Feb 07, 2002 at 04:44:36PM +0100, Miguel Mendez wrote: Hi, I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? I've been unable to log in for almost an hour, the ftp daemon is up, it just doesn't allow me in and I was about to load -CURRENT on my laptop. Any idea? It does seem to be having problems. In the interim, you can use snapshots.jp.freebsd.org... -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org msg34299/pgp0.pgp Description: PGP signature
Re: current.freebsd.org down?
On Thu, Feb 07, 2002 at 04:44:36PM +0100, Miguel Mendez wrote: I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? I've been unable to log in for almost an hour, the ftp daemon is up, it just doesn't allow me in and I was about to load -CURRENT on my laptop. Jordan announced recently that Qwest is upgrading the hardware and that there would be intermittent problems with the server for a certain period (a few days as I recall). Regards -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org down?
I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? Hmm... galtvalion % ftp current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. Name (current.freebsd.org:matusita): ftp 331 Guest login ok, send your email address as password. Password: 550 Can't set guest privileges. ftp: Login failed. ftp ^D 221 Goodbye. galtvalion % ftp stable.freebsd.org ftp: connect: Connection refused galtvalion % Both snapshots machine are not available for services... anybody knows what's going on? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org down?
will Jordan announced recently that Qwest is upgrading the hardware will and that there would be intermittent problems with the server for will a certain period (a few days as I recall). It would be: From: Jordan Hubbard [EMAIL PROTECTED] Subject: stable.freebsd.org AKA releng4.freebsd.org down for next 2 days To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Sat, 02 Feb 2002 13:35:57 -0800 Most people don't mirror anything from this machine, but just for the few who do, please consider this a HEADS UP! The machine is being replaced by a much beefier and faster machine, courtesy of Qwest, and will be back up just as soon as its new incarnation is clearly doing everything the old one did. Now when I say down I also don't mean actually down 24/7, and I'll actually endevor to keep the service mostly up for those two days, I just want you all to know that I'll feel free to reboot it or take it off-line at any time and without notice during that period until the service is transitioned. Thanks for your patience. But this doesn't mention about current.FreeBSD.org, and today is Feb/07/2002. I'm anxious about something goes wrong (machine troubles, jkh is still busy working, or something like that). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
new page cache for linux
Just thought I'd bring your attention to the new radix tree page cache in use by linux - I dont know what freebsd do at the moment, but it looks like it will improve scalability (you guys might want to use the idea). Anyway, heres the link: http://lwn.net/2002/0207/kernel.php3 -- It's not reality or how you perceive things that's important, it's what you're taking for it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ThinkPad X22 PC-Card slot problem
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : From: M. Warner Losh [EMAIL PROTECTED] : Date: Wed, 06 Feb 2002 19:33:32 -0700 (MST) : Hmmm. This looks ugly. :-( I can't boot with acpi enabled on my Dell : Inspiron 8000. I can boot with apm enabled. There are issues with : routing interrupts accross PCI PCI bridges at the moment when the : slots on the other side of the bridge are in the PIR table. : : It turned out that this was not a intterupt routing problem. By : disabling the memory/port range checks in sys/dev/pci/pci_pci.c solved : the problem (below is the patch). pci_pci.c claims that both the : memory adderss for pcic and the PC-Cards are not supported but I could : use the addresses. Yes. This is the ISA problem. The checks are there to make sure we don't assign addresses that aren't decoded by the bridge. However, the bridge does decode ISA addresses. I need to check into which ISA stuff a little better before making a fix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM Error
Yesterday I tried to use SWAT for the first time since the PAM configs were moved from /etc/pam.conf and I'm getting the following error: Feb 6 22:54:05 galaxy swat: PAM _pam_init_handlers: could not open /etc/pam.conf What do I need to do to fix this? TIA, Beech -- --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Thanks for your helpful and pleasant comments David. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
At Wed, 06 Feb 2002 23:33:14 -0500 (EST), John Baldwin wrote: [...] I guess. Note that you can use a loader tunable 'debug.witness_watch' to turn witness off from the loader. If it's set to 0 witness won't be used even if it's compiled into the kernel (just a general FYI, witness(4) documents this as well). Nice feature, thanks for the hint. I can't find it documented in witness(4), however: hunter# grep -i watch /usr/src/share/man/man4/witness.4 hunter# CVSup is from Feb 6. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
* Joe Kelsey [EMAIL PROTECTED] [020207 09:36] wrote: David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. Actually David routinely requests assistance and would like to offload some if not all of the gcc maintainance, the problem he's having is finding people capable and willing to do the work rather than people that just want to draft emails complaining about his current work. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. By stating that he would consider patches he's already given you the go-ahead to do the work, if it's up to par with the project's guidlines there should be minimal fuss with integration. Thanks for your helpful and pleasant comments David. Yeah, whatever, don't we all feel better now? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org down?
This is a different problem. The stable.freebsd.org machine, on which all the really big NFS storage lives, failed to come back up from a reboot last night and I'm trying to get it restarted now. The terminal server also appears to be sick or I'd be able to intervene remotely. :( - Jordan I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? Hmm... galtvalion % ftp current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. Name (current.freebsd.org:matusita): ftp 331 Guest login ok, send your email address as password. Password: 550 Can't set guest privileges. ftp: Login failed. ftp ^D 221 Goodbye. galtvalion % ftp stable.freebsd.org ftp: connect: Connection refused galtvalion % Both snapshots machine are not available for services... anybody knows what's going on? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 01:00:19AM -0800, Terry Lambert wrote: Max Khon wrote: please calm down. seems that you have never installed gcc from ports. gcc 2.95 from ports is installed as gcc295/g++295 and correctly gets its bits from /usr/local/lib/gcc-lib/xxx, gcc 3.0x from ports is named gcc30/g++30 and so on. There is no PATH issue. Switching between compilers is as easy as setting correct CC/CXX environment/Makefile variables. And hacking the Makefile a lot to specify command line arguments in the compiler program definition itself, so that the /usr/include/g++ files that came with the old compiler are not used for make release and other types of make targets where DESTDIR is fairly mandatory. Terry, we only support building the world (ie, anything in /usr/src) with the *SYSTEM* compiler. If you are wanting to do: cd /usr/src make CC=FOOcc CXX=FOO++ buildworld Then you are going off into the not-supported woods and you should expect to have to do some hacking. If you are wanting to use /usr/share/mk for your own projects, then that is also a debatable issue. Some claim /usr/share/mk is only for use of /usr/src; others feel it should be generic and truely usable for other code. If you have some well tested patches to fix the assumptions in /usr/share/mk, we might can change things. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
On Thu, Feb 07, 2002 at 10:15:02AM +0100, Cejka Rudolf wrote: Garance A Drosihn wrote (2002/02/06): Anything else I should check? I realize there's about a million differences between the two branches, and there might also be something about my machine's setup which is a major culprit here. I'm just looking for a basic idea of what other people have been seeing for performance when they run current. There is another common source of confusion: If anybody has IDE disks, write-caching is enabled by default in -stable, but disabled in -current. I don't think that is true anymore. -stable has WC enabled as well. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 12:39:35AM -0500, Mikhail Teterin wrote: I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. GCC does not use bfd -- it does not need to as GCC spits out ASM code, not machine code. Arguing that Binutils and GDB uses the same bfd is a more valid argument. I would like to point out there have been some minor issues with using the bfd from Binutils 2.11.2 with the old GDB 4.x. GCC and GDB does both use libiberty. You will notice that GCC uses its own copy (the files are piled into the src/contrib/gcc directory with the rest of the GCC code). And GDB uses a different copy. This IS the problem I'm trying to solve. WHY do you want to cause this problem of non-matching bits? So they'll be matched and fixed, leading to a better world 8-) I don't know how many times I've said this and why you aren't listening. THEY CANNOT BE MATCHED. Go ask the FSF developers. They will tell you the same thing -- that is why each package's CVS repo maintains its own copy. The FSF developers will tell you using the copy of libiberty is NOT SUPPORTED by them. Evidently, this does not prevent the FreeBSD project from using the same libbfd for its gdb and gcc. Even though, the presense of both Again, see above. This is how little you know of the problem. GCC DOES NOT USE ANY BFD CODE. /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a and /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a is somewhat mistifying to me, but I'm sure they are built from the same source. *SIGH* This also shows how little you know of the make buildworld process. Before you start suggesting the things you have, you really need to start treating ``make buildworld'' as something other than a black box. ``make buildworld'' compiles two copies of some things because of bootstrapping [and cross compiling] issues. No I want to drop Alpha because no one cares about it and not just the compiler, but much more often kernel, WARNS, and other changes break the Alpha. Alright, so you do find it nightmarish. *sigh* NO! Stop putting words in my mouth. I find it extremely ANNOYING. nightmarish != annoying That is NOT a problem. That is just some mis-founded goal with no basis of purpose. Well, than nothing is a problem. Which problem is FreeBSD's very existence trying to solve, huh? Sure some things are a problem. GCC 2.95 generates bad optimized code on the Alpha. Upgrading to 3.1 will fix [some of] this. We cannot do a make buildworld of -CURRENT code on a 4.1 system because of our addition of __FBSDID(). We cannot support 4 GB RAM in any machine (Peter Wemm is working on this); and people need to be able to. Those are real problems. FEH!! You are going to patch the nightmare (yes I will use that term to describe this) autoconf and autoMake bits that come with the GNU tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY THE ORIGINAL AUTHOR INTENDED THEM TO BE. Yes, I very well might. Or, may be, I'll introduce Makefiles of my own -- Something already done for the C compiler and all the other GNU tools in the base, BTW. Submit tested patches and we'll talk farther. But I've seen you have only thought about this off the top of your head with no investigation into the issues. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 10:11:33AM -0800, David O'Brien wrote: On Thu, Feb 07, 2002 at 12:39:35AM -0500, Mikhail Teterin wrote: I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. ... Sure some things are a problem. GCC 2.95 generates bad optimized code on the Alpha. Upgrading to 3.1 will fix [some of] this. We cannot do a To satisfy a bit of my curiosity: - is GCC3 also better on Alpha as far as correctness of the generated code goes? Or is that what you mean by bad optimised code ? - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than on x86. Do you have any idea how gcc3 does in this respect? Thanks! Wilko -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: - is GCC3 also better on Alpha as far as correctness of the generated code goes? Or is that what you mean by bad optimised code ? We shall see. - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than on x86. Do you have any idea how gcc3 does in this respect? 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 10:35:41AM -0800, David O'Brien wrote: On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: - is GCC3 also better on Alpha as far as correctness of the generated code goes? Or is that what you mean by bad optimised code ? We shall see. OK. 8-) - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than on x86. Do you have any idea how gcc3 does in this respect? 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. Thanks. So it is the code generator itself, I always thought it would be the optimiser that needs more time to do a decent job on a RISC. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
On Thu, 7 Feb 2002 19:08:07 +0100 Wilko Bulte [EMAIL PROTECTED] wrote: On Thu, Feb 07, 2002 at 10:15:02AM +0100, Cejka Rudolf wrote: I'm just looking for a basic idea of what other people have been seeing for performance when they run current. There is another common source of confusion: If anybody has IDE disks, write-caching is enabled by default in -stable, but disabled in -current. I don't think that is true anymore. -stable has WC enabled as well. -STABLE has it enabled indeed, but -CURRENT does not (afaik). Read what he said. :-) -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 01:30:22PM -0500, Nat Lanza wrote: Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. Yes there is. Earlier on in the thread I would have used your language. But at this point we are deep in a thread in which I've explained the issues and many people don't seem to be listening. Thus you get the language showing my frustration. Sorry I'm only human. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 07:39:36PM +0100, Wilko Bulte wrote: 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. Thanks. So it is the code generator itself, I always thought it would be the optimiser that needs more time to do a decent job on a RISC. I lumped those two together. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
On Thu, Feb 07, 2002 at 12:41:33AM -0800, Terry Lambert wrote: Ports does the same thing: hand tweaks stuff instead of pushing the patches back to the projects that originated it. *sigh* Terry I respect your programming knowledge, but you are wrong here. I send out a *LOT* of patches to the authors of ports I maintain (and I know others that do so also). You might be surprised at the number of software authors that either 1. don't care that the package is not portable, or 2. wont answer their email. It's far, far better that the Makefile runs the autoconf/automake/configure/etc. on behalf of the contrib code, with no hand-tweaked files dragged in after the config has already been run. That would be nice, but the problem is autoconf/automake/configure/etc. is WAY too sensitive to the environment in which it is running. As one example, the C++ API supported by GCC. When configuring it looks at the existing C++ API and matches it. Well, a while back I wanted to change the C++ API. There is no way to do this using `configure'. However, the way I do build the toolchain it is VERY DETERMINISTIC and I am able to set how I want things to work in the end. This removes dependencies on the current environment. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
thread0 is not the structure itself rather than a pointer that should be the only difference that should affect MD code On 7 Feb 2002, Benno Rice wrote: On Thu, 2002-02-07 at 08:01, Julian Elischer wrote: for the set of patches at: http://www.freebsd.org/~julian/adiff these patches SHOULD NOT EFFECT your system except to do some slight re-aranging of stuff in the kernel. THe aim is to get this committed to 'clarify' the upcoming KSE commit in http://www.freebsd.org/~julian/thediff which includes adiff as a subset. when adiff is committed thediff will become a lot easier for people to read and check. I'd like to get adiff in relatively soon. This causes some breakage in PowerPC but I'm working on it. Go ahead and commit and I'll fix PowerPC up after. -- Benno Rice [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
* Nat Lanza [EMAIL PROTECTED] [020207 10:30] wrote: On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. No, they both offer users a chance to conribute, however the second let's the person know that they are bordering on annoying the person and should take some time to work on the actual implementation. Would you rather have someone's irritation or just be killfiled? Some people need to buck up and grow a thicker skin. Neither I nor David are in anyway compensated directly through our involvement in the FreeBSD project to pull punches nor coddle people that should know better. Moving forward, let's postpone taking this conversation any further until the time that the work requested does become available. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bizzare problem..
On Wed, 6 Feb 2002, Jacob Frelinger wrote: On Wed, Feb 06, 2002 at 01:08:10PM -0800, Doug White wrote: On Tue, 5 Feb 2002, Jacob Frelinger wrote: You aren't using a Linux version of vi, are you? It so happens a common freebsd system call maps to linux reboot() it shouldn't be. [jolly@spooky ~]# which vi /usr/bin/vi [jolly@spooky ~]# strings /usr/bin/vi | head -2 /usr/libexec/ld-elf.so.1 FreeBSD and that wouldn't explain the shutdowns when i ssh from the problematic machine into a different one and run vi on the remote machine. i wish it was something that simple... i'm completly stumped on this... I think I'd chock it up to bad memory at this point. Teh reboots could be a parity failure and some systems reboot in that condition ... Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
MODULES_WITH_WORLD=true means no modules?
Is it just me, or... I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. I just finished the buildworld/kernel/install jig, and I've got a fistful of modules built in /usr/obj/5.0-CURRENT/usr/src/sys/modules but after both installkernel and installworld, I've got an empty /boot/modules, and the only inhabitant of /boot/kernel/ is kernel. /boot/kernel.old/ is where I can find old modules, from when I built things the default way (build a new kernel, modules too) Either the modules aren't getting installed, or some other thing I've changed in /etc/make.conf (like the /usr/obj/5.0-CURRENT prefix) has hosed the modules install process. Is someone else using `MODULES_WITH_WORLD=true' successfully? If so, I'll boot back into -current and see if I can check it out... thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb mouse won't work
Doug White wrote: On Mon, 4 Feb 2002, Peter Schultz wrote: FreeBSD does not want to work with my USB mouse. I believe it to be a problem with the motherboard, a Tyan S1834. The mouse does work under BeOS and Windows so I know it's not toast. Also, the mouse works with FreeBSD on my Tyan S1832 motherboard so that's a good sign too. You cut off the initial attach message, so there's nothing useful in your message. No I didn't, it was in the dmesg output, unless you mean something else. Is this it: Feb 4 20:51:55 max kernel: ums0: Logitech USB-PS/2 Mouse, rev 1.00/1.20, addr 2, iclass 3/1 Feb 4 20:51:55 max kernel: ums0: 3 buttons Feb 4 20:51:55 max kernel: ums_attach: sc=0xc1eb0400 Feb 4 20:51:55 max kernel: ums_attach: X 8/8 Feb 4 20:51:55 max kernel: ums_attach: Y 16/8 Feb 4 20:51:55 max kernel: ums_attach: B1 0/1 Feb 4 20:51:55 max kernel: ums_attach: B2 1/1 Feb 4 20:51:55 max kernel: ums_attach: B3 2/1 Feb 4 20:51:55 max kernel: ums_attach: size=3, id=0 What kind of mouse is this? A Logitech WingMan. Someone sent me a patch which is supposed to work with -STABLE, but PCI_COMMAND_STATUS_REG isn't defined in -CURRENT so it didn't help. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
Julian Elischer writes: I've committed both the kernel diff and a libkvm diff that seems to work for me here. can you check it with the new -current again ? I'll build a kernel I'll be happy to try a buildworld under it. But from what I understand, the new binutils is broken and alpha binaries built with it segv, so I don't really want to install whatever I build :-( Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Alfred Perlstein wrote: Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. A lot of us are punch-drunk with the upcoming BSDCon next week, too. The flipness of the comments aside (don't hold people's personalities against them, Joe), doing a patch would be a way to handle this. I offered to help with the structural stuff, but not write the patch itself, since I'm not really a great follower of -current, and patches not against current are frequently ignored by committers because they don't represent the latest, greatest thing. I still haven't figured out how to hande the dichotomy of most volunteer work occurring in -current, while most commercial work on FreeBSD occurs in the last RELEASE, or, to a lesser extent, -stable. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. It's not a trivial problem to fix, either. It's tangled up in the make release process, which is two measures of intent down the road from the question that Joe asked. I volunteered structural help (which would probably be mostly just explaqining the status quo, so that anyone writing the code could avoid breakage), and David volunteered to do reviews of the resulting patches, which is tantamount to volunteering to commit them, so long as they aren't incredibly offensive. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. I don't think Joe is debating; I think he wants to have a meta-discussion about what the problem space looks like, before submitting patches that light up his little corner, and dark up everything else. Every time these tools issues come up, it really boils down to the GNU build process sucking pretty hard, not being very seperable, and, in general, expecting to be installed in isolation as an add on, rather than as an integral part of a larger whole. You really can't hold David responsible for that, it's a vendor problem that doesn't look to be solved any time soon. USL is the same way: they have some incredibly smart stuff, but interacting with them is like sharing a prison cell with a 500 pound man named Bubba, even if you are their employee. Maybe especially if you are their employee... guards have to see Bubba every day of their career, while short timers have the promise that their Bubba days will soon be over. 8-). It's also not obvious that the DESTDIR phenomenon exists with compilers from ports, until you get going and it bites you on the arse. David is the compiler maintainer, so it's second nature to him to turn around and smack problems as they are preparing to bite. 8-). The rest of us end up with rather more tender backsides... 8-) 8-). I don't think that this is going to be resolved right before BSDCon, when everyone is feeling incredible time pressure, and those who aren't are having the stress rubbed off onto them by the others. I also don't think that this is a shallow problem that's subject to easy dismissal. But if it's a choice between have some, everything works, and have all, some works, the everything works wins hands down. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Lock order reversal on shutdown
In noticed this lock order reversal while shutting down the system to single-user in order to make installworld of my cvsup of today. I then tried again with the new world and the l.o.r. was still there. lock order reversal 1st 0xc0409dc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc4141e34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Terry Lambert writes: I don't think Joe is debating; I think he wants to have a meta-discussion about what the problem space looks like, before submitting patches that light up his little corner, and dark up everything else. Thank you, Terry. Maybe I need to bring up the issue on -arch? Where is it possible to have design discussions without getting slapped down with the submit a patch or shut up attitude? I personally work by doing design first, or at least getting to the point where I understand the problem before tackling it in an incremental design/build cycle. Maybe someone can point out the design documentation for the whole complex mk hierarchy and/or for the design behind the importation of gcc and other GNU stuff into the source tree. Or maybe the design is the code... I appreciate your offer of assistance, Terry. I will take your last pointer into the make files and see what I can deduce on my own. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien wrote: And hacking the Makefile a lot to specify command line arguments in the compiler program definition itself, so that the /usr/include/g++ files that came with the old compiler are not used for make release and other types of make targets where DESTDIR is fairly mandatory. Terry, we only support building the world (ie, anything in /usr/src) with the *SYSTEM* compiler. If you are wanting to do: cd /usr/src make CC=FOOcc CXX=FOO++ buildworld Then you are going off into the not-supported woods and you should expect to have to do some hacking. The problem I noted is C++ only. I'm sure that there are other cases where it's not, but they're really fuzzy, since I don't have a comprehensive tool chain listing that can get me an explosion if anything from the default chain gets used accidently. Wasn't Eric Melville going to fix this by turning the normal system components into packages? 8-) 8-). For the buildworld case, and the release case, the problem is incredibly deeper than just replacing the day to day use tools, since if you build the compiler as part of the build, you're screwed already. You can make an argument for the release case using a different set of tools, since it can install patches and packages prior to the build process, but the compiler you end up with will be the release compiler, not the package compiler, even though pretty much everything will have been compiled with the package compiler (or cross builds would not work at all). Even so, the interaction is ugly. I think Joe's main problem is that it's not documented, except in the heads of the people who've tried it, or the people who maintain it. Yeah, that's a problem, but the only thing we can really do about it is offer to answer questions, or tell them (or imply with a where's the patches? response) that they are on their own. Documentation won't magically appear (e.g.: where's the patches? 8-)). If you are wanting to use /usr/share/mk for your own projects, then that is also a debatable issue. Some claim /usr/share/mk is only for use of /usr/src; others feel it should be generic and truely usable for other code. If you have some well tested patches to fix the assumptions in /usr/share/mk, we might can change things. Seperate problem. Though if it *were* generic... we might see the BSD make being more widely adopted. I think this is one of the tenets of the Open Ports project, FWIW. If nothing else, FreeBSD ought to be pulling back in their tools changes that they've found to be necessary, so long as they don't hurt too much (a little pain is good for you, according to the penguins...). Personally, if my projects are limited to FreeBSD, I use the .mk system, and if they aren't, then I avoid it like the plague. Building a project based partly on Open Source is really an art, more than it is an easy thing to do, though it's often worth the pain to get the benefits (per my Daemon News article -- shameless plug). I think the biggest barrier these days is that there is so much that is assumed to be part of the base system that is not really generic UNIX, and avoiding contamination from use of, for example, the FreeBSD version of OpenSSL, rather than the version in your source tree, requires that the engineer doing the work cross their T's and dot their I's correctly, or they will find that their code works on their developement machine, but not their target machine. Fixing *that* problem is a lot more than just waving your hands: it requires duct tape and prayers, since you will find yourself fixing the software packages you depend upon, too (this is the major drawback of autconf/automake: unlike imake and xmkmf, they really aren't portability tools, and can't make a program run on a new target through a correct description of the target, like imake can -- e.g. MySQL now runs on AIX again because I hit my head on it, and there are 5 or 6 other Open Source projects that got patches out of my last round of head hitting). In any case, it's often hard to discuss Hoover Dam when you are running low on fingers plugging holes in the local levy; know that your work on the levy *is* appreciated, since we would all be under water otherwise. I'll look at what it will take to fix the DESTDIR stuff without breaking things. That's a far cry from what Joe wanted, but it's a step in that direction, anyway. It's going to boil down to tracking down everywhere it's used in the source tree as is, particularly with regards to the make release case, where the headers have to come in from the target environment, but also in ports. 8-(. Fortunately, there is not a lot of C++ code in the release stuff; the ports stuff will be more problematic, of course, but much of that is already broken, in that the system compiler is passed, but the g++ compiler is searched out and preferred (!@#!$!@ autoconf/automake). ...Uh, don't let me looking at this stop anyone else from looking at it
Re: Performance of -current vs -stable
Wilko Bulte wrote: There is another common source of confusion: If anybody has IDE disks, write-caching is enabled by default in -stable, but disabled in -current. I don't think that is true anymore. -stable has WC enabled as well. Friends don't let friends cache writes ??? [1/2] 8-)... some IDE drives lie, when you tell them to flush their caches. [1] 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MODULES_WITH_WORLD=true means no modules?
MODULES_WITH_WORLD=true # do not build modules when building kernel ^^^ ...you need to read the option you enabled? Never mind, I figured out what happened, and will happen again in the future, since this doesn't quite `optimize' things as I'd like I had actually started writing to ask why /boot/kernel.old hadn't been updated with my previous /boot/kernel, but then I figured it out. Since I had done two `installkernel's, I was using the kernel image in /boot/kernel.old/ from the first installkernel, and a test is made, so that if I'm using it, it doesn't get deleted. Instead, what happened was that the existing /boot/kernel contents were nuked. This had been populated by kernel modules by the installworld step that I did following the first installkernel. So, when the above option is enabled, normally your previous contents of /boot/kernel/ are moved to replace /boot/kernel.old/ by `installkernel' and the new contents of /boot/kernel/ are no more than kernel alone -- look ma, no modules! In order to get /boot/kernel/ populated with modules, either one needs to installworld again, or use one of the targets to install only modules, I guess. Actually, on this machine, a complete installworld probably takes less time than the present way to build a fresh kernel and set of modules as the `buildkernel' step, which I had hoped would be sped up. What I had perhaps been thinking (if you could claim that I was in fact thinking at all) was that the modules would be installed into a location by `installworld' that would be independent of any `build/installkernel's that would follow -- such as /boot/modules, which appears in the sysctl kern.module_path under -current. That way one could build new kernels from the same source, adding or removing devices, only needing to update the modules as part of the installworld when the source gets changed. At least, that was my goal in enabling this /etc/make.conf option, to speed up the buildkernel/installkernel process by skipping module rebuilding any time I swap in a different ethernet or sound card or find a new spiffy kernel option to try out. That's it in a nutshell. FWIW, booting the new kernel just built a few hours ago gives the following: | CPU: Pentium/P54C (75.00-MHz 586-class CPU) | Origin = GenuineIntel Id = 0x524 Stepping = 4 | Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 = WARNING: Driver mistake: make_dev(perfmon) called before SI_SUB_DRIVERS | real memory = 41943040 (40960K bytes) Once again, I fling off a message before engaging brane barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 02:55:26PM -0800, Terry Lambert wrote: stuff; the ports stuff will be more problematic, of course, but much of that is already broken, in that the system compiler is passed, but the g++ compiler is searched out and preferred (!@#!$!@ autoconf/automake). env CXX=foo++ ./configure To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
David O'Brien wrote: 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. I don't think this is definative. I think the problem is that the GCC code for the code generation on these platforms is not beaten on very heavily by people who care about it. We see the same effect in FreeBSD from time to time, when the Alpha build is broken for one reason or another by a supposedly platform independent change which is really an x86-ism. I suspect code generation for these platforms will be slow, but that code generation for the 64 bit Intel and AMD processors will be a lot faster. The Alpha stuff is also hampered by the instruction reordering, which is another pass, but that doesn't fully account for the slowness of the code (IMO). Probably, it could be made much faster by someone who cared about it, and who has a profile in hand. Personally, I was happy with my 1 MHz 6502, so as far as I see it, everything runs blazingly fast, even though modern programmers fail on cycle squezing by multiple orders of magnitude most times. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On 7 Feb 2002, Nat Lanza wrote: Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. I humbly have to agree that was the way it sounded to me. Im hoping that it was not meant that way, but that was howe it sounded. /Johan --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
David O'Brien wrote: Ports does the same thing: hand tweaks stuff instead of pushing the patches back to the projects that originated it. *sigh* Terry I respect your programming knowledge, but you are wrong here. I send out a *LOT* of patches to the authors of ports I maintain (and I know others that do so also). You might be surprised at the number of software authors that either 1. don't care that the package is not portable, or 2. wont answer their email. Actually, I wouldn't. I started on a pass thorugh the ports a while back, to try and push patches back to the authors, but it's a daunting task. A lot of the ports patches (and I'm not trying to dump on anyone in particular here... I didn't start by going alphabetically ;-)) are unfortunately not push-backable. The FreeBSD specific patches break things for other platforms, or end up changing things for editorial reasons, without making the targets of those changes site options, instead of an editorial conflict with the authors of the original code (DJB is particularly bad at portraying any patch offered him as if it were an editorial comment, but other authors are not immune to the same thing, unfortunately). Needless to say, it would take a concerted effort to get rid of the FreeBSD specific patches out of the ports tree, entirely, not just the efforts of one person. A quick perusal of the /usr/ports on a 4.1 machine I have here locally (quick perusal?!? 8-)) shows that there are ~8000 patch files that are needed to FreeBSD-ify things, and that number is likely much higher with the higher number of ports, now. Maybe Open Ports, being a voice for more OSs, will have better luck. It's far, far better that the Makefile runs the autoconf/automake/configure/etc. on behalf of the contrib code, with no hand-tweaked files dragged in after the config has already been run. That would be nice, but the problem is autoconf/automake/configure/etc. is WAY too sensitive to the environment in which it is running. As one example, the C++ API supported by GCC. When configuring it looks at the existing C++ API and matches it. Well, a while back I wanted to change the C++ API. There is no way to do this using `configure'. However, the way I do build the toolchain it is VERY DETERMINISTIC and I am able to set how I want things to work in the end. This removes dependencies on the current environment. Ugh. I was unaware that they tried to do that. It seems... uh... brilliant... to want to lock everyone into the 1.0 version of the API because they upgraded through all the g+ version since day 1. 8-p. Unless there are overriding concerns like that, though, I think that people doing ports should do as you say, not as you do. 8-). GCC is, unfortunately, a very big pile of code; if anything's going to be an exception, it's that, particularly given the release and buildworld issues. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
On Thu, Feb 07, 2002 at 04:28:03PM -0500, Andrew Gallatin wrote: Julian Elischer writes: I've committed both the kernel diff and a libkvm diff that seems to work for me here. can you check it with the new -current again ? I'll build a kernel I'll be happy to try a buildworld under it. But from what I understand, the new binutils is broken and alpha binaries built with it segv, so I don't really want to install whatever I build :-( No you don't. I did accidentally. Don't :( -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VMware Workstation 3.0 For FreeBSD
Does anyone know if there is an active effort to port VMware Workstation 3.0 for Linux to run under FreeBSD ?? Version 2 of Workstation is no longer avaiable it seems... Thanks, Glenn G. Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien wrote: stuff; the ports stuff will be more problematic, of course, but much of that is already broken, in that the system compiler is passed, but the g++ compiler is searched out and preferred (!@#!$!@ autoconf/automake). env CXX=foo++ ./configure I had to be a bit more agressive with the packages I was fighting. I can look up which ones they were, if you want. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
World breakage (lib/libroken)
Is this the problem on my local environment only? === libroken awk -f /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.h.in make-roken.c awk: /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk:18: warning: escape sequence `\#' treated as plain `#' cc -O -mpentiumpro -pipe -march=pentiumpro -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I/usr/obj/usr/src/kerberos5/lib/libroken -Wall -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../include -DHAVE_CONFIG_H -DINET6 -I/usr/obj/usr/src/i386/usr/include make-roken.c -o make-roken /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lc *** Error code 1 Stop in /usr/src/kerberos5/lib/libroken. *** Error code 1 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ucred for threads
As part of the KSe stuff I ended up changing ht ebehaviour of threads with
respect to their ucreds. Previously, they freed their ucred reference when
they entered user space and picked them up again when they re-entered the
kernel. It there was an AST then they re-loaded teh already freed ucred to
perform the AST. (and then freed it again, (For each AST).
Since each 'get' and free required a lock and unlock of the proc
structure, this meant that there were at least 2 locks and 2 unlocks, and
possibly many more, for the average kernel entry/exit pair.
Since the chance that the ucred on the next entry is not the same as the
thread already had on it's last kernel exit, is almiost negligible,
it makes sence to hold the ucred acress the user period an dsimply check
it agains the process's ucred on th enext entry.
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: MODULES_WITH_WORLD=true means no modules?
On Thu, Feb 07, 2002 at 09:57:47PM +0100, BOUWSMA Beery wrote: I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. You might find these targets more useful than the above: make kernel make install-kernel make reinstall-modules To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
Julian Elischer writes: I've committed both the kernel diff and a libkvm diff that seems to work for me here. can you check it with the new -current again ? World breakage on alpha: usr/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c: In function `set_proc_cmd': /usr/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c:393: structure has no member named `p_thread' *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. *** Error code 1 The following diff fixes it, but isn't likely to be correct. How should kvm be finding the pcb based on the process? Drew Index: kvm-fbsd.c === RCS file: /home/ncvs/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c,v retrieving revision 1.6 diff -u -r1.6 kvm-fbsd.c --- kvm-fbsd.c 13 Oct 2001 04:38:46 - 1.6 +++ kvm-fbsd.c 8 Feb 2002 01:39:32 - @@ -390,7 +390,7 @@ addr = (CORE_ADDR)parse_and_eval_address(arg); /* Read the PCB address in proc structure. */ - addr += (int) ((struct proc *)0)-p_thread.td_pcb; + addr += (int) ((struct proc *)0)-p_xxthread.td_pcb; if (kvread(addr, val)) error(cannot read pcb ptr); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
Julian Elischer wrote:
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
You can't have a process with a thread without a ucred, right?
If so, then the idea is sound, but the code is broken.
In the case that they are not equal, you free it, null
the pointer, and don't allocate a replacement.
What is the default state of td-td_ucred?
In theory, it should be initialized on creation, and then
left initialized (you are effectively lazy binding the cred
references).
Since the reference count is positive in both cases, an
unlocked pointer comparison is fine. In the case where
there is a race on a credential change in the unlocked
value, that race exists in the calling code, anyway. The
failure case in a change for-to instead of to-from is
also safe, since the pointers will be inequal during the
update, the lock will be held during the update, so the
subsequent release and regrab with the increment never
dropping below 1.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
td-td_ucred = crhold(p-p_ucred);
PROC_UNLOCK(p);
}
Is a thread lock required? I think it's guaranteed to
be non-reentrant, so the answer should be no...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
ok here's the fix that went into libkvm http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libkvm/kvm_proc.c.diff?r1=1.41r2=1.42 basically you have to map in the thread structure separatly to the proc structure, using the first entry in the linked list of threads. Obviously this only works for a process with one thread but the program will need more help than that to handle more than one thread. kvread and KREAD are basically the same thing. basically you have read in teh thread structure and then read the pcb from there.. On Thu, 7 Feb 2002, Andrew Gallatin wrote: Julian Elischer writes: I've committed both the kernel diff and a libkvm diff that seems to work for me here. can you check it with the new -current again ? World breakage on alpha: usr/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c: In function `set_proc_cmd': /usr/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c:393: structure has no member named `p_thread' *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. *** Error code 1 The following diff fixes it, but isn't likely to be correct. How should kvm be finding the pcb based on the process? Drew Index: kvm-fbsd.c === RCS file: /home/ncvs/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c,v retrieving revision 1.6 diff -u -r1.6 kvm-fbsd.c --- kvm-fbsd.c13 Oct 2001 04:38:46 - 1.6 +++ kvm-fbsd.c8 Feb 2002 01:39:32 - @@ -390,7 +390,7 @@ addr = (CORE_ADDR)parse_and_eval_address(arg); /* Read the PCB address in proc structure. */ - addr += (int) ((struct proc *)0)-p_thread.td_pcb; + addr += (int) ((struct proc *)0)-p_xxthread.td_pcb; if (kvread(addr, val)) error(cannot read pcb ptr); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
On Thu, 7 Feb 2002, Terry Lambert wrote:
Julian Elischer wrote:
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
You can't have a process with a thread without a ucred, right?
yes.. well in booting yuo can have a null ucred. ( I know,s
I've hit it), but in general you are correct.
If so, then the idea is sound, but the code is broken.
In the case that they are not equal, you free it, null
the pointer, and don't allocate a replacement.
ummm yes I do, assuming that there is one to allocate...
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
What is the default state of td-td_ucred?
on creation, NULL followed very rapidly with being set to
p-p_ucred. (via crhold)
In theory, it should be initialized on creation, and then
left initialized (you are effectively lazy binding the cred
references).
yes..
Since the reference count is positive in both cases, an
unlocked pointer comparison is fine. In the case where
there is a race on a credential change in the unlocked
value, that race exists in the calling code, anyway. The
failure case in a change for-to instead of to-from is
also safe, since the pointers will be inequal during the
update, the lock will be held during the update, so the
subsequent release and regrab with the increment never
dropping below 1.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
without the if it crashes in boot sometimes.
(this may not be true right now but was during my testing of
the KSE kernel)
td-td_ucred = crhold(p-p_ucred);
PROC_UNLOCK(p);
}
Is a thread lock required? I think it's guaranteed to
be non-reentrant, so the answer should be no...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
possible world breakage warning..
there may be greakage in gdb due th the commit today.. I'm waiting for my buildworld to get sround to it so I can test my fix.. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VMware Workstation 3.0 For FreeBSD
Does anyone know if there is an active effort to port VMware Workstation 3.0 for Linux to run under FreeBSD ?? Version 2 of Workstation is no longer avaiable it seems... It is still available, in the Support/Archive section of their website. I'd love to know if someone plans to port 3.0 though, because it offers a lot of added functionality... Best regards, Andrzej // // Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // // [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
time breakage.
phk, is this you? c++ -g -O -pipe -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc -o new.o In file included from /usr/include/sys/stat.h:50, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include/posix.h:22, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc:24: /usr/include/sys/time.h: In function `void timespec2bintime(timespec *, bintime *)': /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned /usr/include/sys/time.h: In function `void timeval2bintime(timeval *, bintime *)': /usr/include/sys/time.h:153: integer constant out of range /usr/include/sys/time.h:153: warning: decimal integer constant is so large that it is unsigned *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs/libgroff. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
Julian Elischer wrote:
yes.. well in booting yuo can have a null ucred. ( I know,s
I've hit it), but in general you are correct.
[ ... ]
What is the default state of td-td_ucred?
on creation, NULL followed very rapidly with being set to
p-p_ucred. (via crhold)
Non-problem, then.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
without the if it crashes in boot sometimes.
(this may not be true right now but was during my testing of
the KSE kernel)
The place to fix this is by setting up a default reference to
a root/boot ucred, I think, for use by the initial process
template.
What are the consequences, if any, of me having removed the
setting the thing to NULL, during boot? I guess that it
would leave the thread cred uninitialized. Obviously, the
problem with your crash is in the crhold( NULL). 8-).
It seems to me that the test would leave threads with NULL
ucreds around as well, and just complicate things later.
Is there a reason you can't set up an initial ucred?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: possible world breakage warning..
On Thu, 7 Feb 2002, Julian Elischer wrote:
there may be greakage in gdb due th the commit today..
I'm waiting for my buildworld to get sround to it so I can test my fix..
julian
the fix I am looking at testing is:
Index: i386/kvm-fbsd.c
===
RCS file: /usr/home/cvs/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c,v
retrieving revision 1.33
diff -u -r1.33 kvm-fbsd.c
--- i386/kvm-fbsd.c 2001/12/12 21:15:30 1.33
+++ i386/kvm-fbsd.c 2002/02/08 02:36:43
@@ -387,9 +387,12 @@
int regno;
{
struct pcb *pcbaddr;
+ struct thread *td;
/* find the pcb for the current process */
- if (cur_proc == NULL || kvread (cur_proc-p_thread.td_pcb,
pcbaddr)) /* XXXKSE */
+ if (cur_proc == NULL ||
+ kvread (TAILQ_FIRST(cur_proc-p_threads), td) || /* XXXKSE */
+ kvread (td-td_pcb, pcbaddr)) /* XXXKSE */
error (cannot read u area ptr for proc at %#x, cur_proc);
if (read_pcb (core_kd, (CORE_ADDR)pcbaddr) 0)
error (cannot read pcb at %#x, pcbaddr);
in the gdb sources but haven't managed to test it yet.
due to other breakages..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
Terry I don't have time to work on it now, but if you would like to take a
-current system
and apply the threading KSE diffs from my web page,
then maybe you can investigate whether I really ned the if clause or
not..
I don't have time now to go back to it for a while
On Thu, 7 Feb 2002, Terry Lambert wrote:
Julian Elischer wrote:
yes.. well in booting yuo can have a null ucred. ( I know,s
I've hit it), but in general you are correct.
[ ... ]
What is the default state of td-td_ucred?
on creation, NULL followed very rapidly with being set to
p-p_ucred. (via crhold)
Non-problem, then.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
without the if it crashes in boot sometimes.
(this may not be true right now but was during my testing of
the KSE kernel)
The place to fix this is by setting up a default reference to
a root/boot ucred, I think, for use by the initial process
template.
What are the consequences, if any, of me having removed the
setting the thing to NULL, during boot? I guess that it
would leave the thread cred uninitialized. Obviously, the
problem with your crash is in the crhold( NULL). 8-).
It seems to me that the test would leave threads with NULL
ucreds around as well, and just complicate things later.
Is there a reason you can't set up an initial ucred?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
On 07-Feb-02 Georg-W Koltermann wrote: At Wed, 06 Feb 2002 23:33:14 -0500 (EST), John Baldwin wrote: [...] I guess. Note that you can use a loader tunable 'debug.witness_watch' to turn witness off from the loader. If it's set to 0 witness won't be used even if it's compiled into the kernel (just a general FYI, witness(4) documents this as well). Nice feature, thanks for the hint. I can't find it documented in witness(4), however: hunter# grep -i watch /usr/src/share/man/man4/witness.4 hunter# CVSup is from Feb 6. Hmm, doh. I document the other loader tunables and sysctls, just not debug.witness_watch. If someone with some mdoc fu and spare time wants to add a para noting that debug.witness_watch can be set to 0 as a loader tunable to turn off witness and that the read-only sysctl debug.witness_watch can be used at runtime to see if witness is enabled or not. -- Regards, Georg. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
Julian Elischer wrote: Terry I don't have time to work on it now, but if you would like to take a -current system and apply the threading KSE diffs from my web page, then maybe you can investigate whether I really ned the if clause or not.. I don't have time now to go back to it for a while I normally don't do -current, but I'm in the process of pulling together a tree right now. If I find time after the tasks I need to get done (i.e. real work), then I'll look at setting up an initial ucred, since it's really bogus to put if tests all over creation because initialization didn't end up normalizing things. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: ucred for threads
On 08-Feb-02 Julian Elischer wrote:
As part of the KSe stuff I ended up changing ht ebehaviour of threads with
respect to their ucreds. Previously, they freed their ucred reference when
they entered user space and picked them up again when they re-entered the
kernel. It there was an AST then they re-loaded teh already freed ucred to
perform the AST. (and then freed it again, (For each AST).
Since each 'get' and free required a lock and unlock of the proc
structure, this meant that there were at least 2 locks and 2 unlocks, and
possibly many more, for the average kernel entry/exit pair.
Since the chance that the ucred on the next entry is not the same as the
thread already had on it's last kernel exit, is almiost negligible,
it makes sence to hold the ucred acress the user period an dsimply check
it agains the process's ucred on th enext entry.
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
This code is not safe on SMP non-i386 machines (i.e. ia64, sparc64, alpha, and
possibly p3 and later i386's) because the p_ucred value you read could easily
be a stale value, thus rendering the test invalid. You need the lock for the
compare. Conceptually minimizing the crfree's isn't bad I guess. However, the
td_ucred pointer should nto be read if the thread is not in the kernel, and
having it set to NULL when we leave the kernel provides a conveninet way of
ensuring this doesn't happen since we will panic if we do.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
On 08-Feb-02 Terry Lambert wrote: Since the reference count is positive in both cases, an unlocked pointer comparison is fine. In the case where there is a race on a credential change in the unlocked value, that race exists in the calling code, anyway. The failure case in a change for-to instead of to-from is also safe, since the pointers will be inequal during the update, the lock will be held during the update, so the subsequent release and regrab with the increment never dropping below 1. No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed on some other processor by another thread from this processor? Without a lock you don't have a guarantee that that other processor's writes are visible to you. We really don't want to be using stale credentials for syscalls given the past history of race conditions involving credentials. If in the future it is deemed that getting a stale cred is an acceptable race, then this can be optimized then, but for now we had better get it right. FreeBSD doesn't run on just the i386 anymore, we have Alpha, ia64, and sparc64 SMP machines to deal with as well. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bremfree related panic
I rebuilt my -CURRENT workstation last night. There still seems to be a
minor problem though. While I was running XFree 3.x (a rather old build,
compiled from ports):
$ pkg_info | grep XFree
XFree86-3.3.6_9 X11R6.3/XFree86 core distribution
there was the following panic. At the same time the disk was heavily
spinning, as I was updating my local NetBSD mirror with CVSup, and periodic
was running it's daily stuff. Does this look like a problem with X to you
all, or should I look for other causes? I am thinking of X giving me these
troubles, only because of frame #13 which is in an address that cannot be
printed by gdb. Any ideas?
(The bremfree panic is the second panic in the row, so it's probably a
whole different problem in itself.)
Script started on Fri Feb 8 05:55:22 2002
[toor@hades /var/crash]# gdb -k /usr/obj/usr/src/sys/CHARON/kernel.debug vmcore.1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
IdlePTD at phsyical address 0x003d1000
initial pcb at physical address 0x00329bc0
panicstr: bremfree: bp 0xc2161734 not locked
panic messages:
---
panic: msleep
syncing disks... panic: bremfree: bp 0xc2166e4c not locked
Uptime: 2d15h0m41s
dumping to dev ad0s3b, offset 1966080
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37
36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
6 5 4 3 2 1
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
504 if (!dodump)
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
#1 0xc01b8ec4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:336
#2 0xc01b9361 in panic (fmt=0xc02b5da2 bremfree: bp %p not locked) at
/usr/src/sys/kern/kern_shutdown.c:646
#3 0xc01e7ecf in bremfree (bp=0xc2161734) at /usr/src/sys/kern/vfs_bio.c:545
#4 0xc0196359 in spec_fsync (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:407
#5 0xc0195e51 in spec_vnoperate (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#6 0xc024d449 in ffs_sync (mp=0xc0e00200, waitfor=2, cred=0xc05bee00,
td=0xc02f9604) at vnode_if.h:441
#7 0xc01f4c42 in sync (td=0xc02f9604, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:669
#8 0xc01b8b46 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:245
#9 0xc01b9361 in panic (fmt=0xc02cb2fe %s) at
/usr/src/sys/kern/kern_shutdown.c:646
#10 0xc0289d78 in trap_fatal (frame=0xc03d5fa8, eva=791205) at
/usr/src/sys/i386/i386/trap.c:842
#11 0xc0289aad in trap_pfault (frame=0xc03d5fa8, usermode=0, eva=791205) at
/usr/src/sys/i386/i386/trap.c:756
#12 0xc02895ef in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 51676,
tf_esi = 1816, tf_ebp = 264, tf_isp = -1069719596,
tf_ebx = 264, tf_edx = 980, tf_ecx = 6930, tf_eax = 0, tf_trapno = 12, tf_err
= 4, tf_eip = 4773, tf_cs = 49152,
tf_eflags = 721478, tf_esp = 4000, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:426
#13 0x12a5 in ?? ()
Cannot access memory at address 0x108.
(kgdb) list /usr/src/sys/kern/vfs_bio.c:545
540 int old_qindex = bp-b_qindex;
541
542 GIANT_REQUIRED;
543
544 if (bp-b_qindex != QUEUE_NONE) {
545 KASSERT(BUF_REFCNT(bp) == 1, (bremfree: bp %p not
locked,bp));
546 TAILQ_REMOVE(bufqueues[bp-b_qindex], bp, b_freelist);
547 bp-b_qindex = QUEUE_NONE;
548 } else {
549 if (BUF_REFCNT(bp) = 1)
(kgdb) list /usr/src/sys/i386/i386/trap.c:426
421
422 KASSERT(cold || td-td_ucred != NULL,
423 (kernel trap doesn't have ucred));
424 switch (type) {
425 case T_PAGEFLT: /* page fault */
426 (void) trap_pfault(frame, FALSE, eva);
427 goto out;
428
429 case T_DNA:
430 #ifdef DEV_NPX
(kgdb) q
[toor@hades /var/crash]# exit
Script done on Fri Feb 8 05:56:52 2002
Here's the dmesg output too:
Copyright (c) 1992-2002 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
Re: new page cache for linux
Nero wrote: Just thought I'd bring your attention to the new radix tree page cache in use by linux - I dont know what freebsd do at the moment, but it looks like it will improve scalability (you guys might want to use the idea). Anyway, heres the link: http://lwn.net/2002/0207/kernel.php3 You should look at how FreeBSD already handles this problem. Note also that as physical memory approaches real memory in size, the sparseness of the mapping goes to zero. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: bremfree related panic
On 08-Feb-02 Giorgos Keramidas wrote:
(The bremfree panic is the second panic in the row, so it's probably a
whole different problem in itself.)
Yep.
IdlePTD at phsyical address 0x003d1000
initial pcb at physical address 0x00329bc0
panicstr: bremfree: bp 0xc2161734 not locked
panic messages:
---
panic: msleep
Hmmm, wonder where that came from.
oh:
KASSERT(ident != NULL td-td_proc-p_stat == SRUN, (msleep));
However, your trace shows some other type of panic, one not in msleep but from
a fatal kernel trap.
Weird.
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
504 if (!dodump)
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
#1 0xc01b8ec4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:336
#2 0xc01b9361 in panic (fmt=0xc02b5da2 bremfree: bp %p not locked) at
/usr/src/sys/kern/kern_shutdown.c:646
#3 0xc01e7ecf in bremfree (bp=0xc2161734) at
/usr/src/sys/kern/vfs_bio.c:545
#4 0xc0196359 in spec_fsync (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:407
#5 0xc0195e51 in spec_vnoperate (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#6 0xc024d449 in ffs_sync (mp=0xc0e00200, waitfor=2, cred=0xc05bee00,
td=0xc02f9604) at vnode_if.h:441
#7 0xc01f4c42 in sync (td=0xc02f9604, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:669
#8 0xc01b8b46 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:245
#9 0xc01b9361 in panic (fmt=0xc02cb2fe %s) at
/usr/src/sys/kern/kern_shutdown.c:646
#10 0xc0289d78 in trap_fatal (frame=0xc03d5fa8, eva=791205) at
/usr/src/sys/i386/i386/trap.c:842
#11 0xc0289aad in trap_pfault (frame=0xc03d5fa8, usermode=0, eva=791205) at
/usr/src/sys/i386/i386/trap.c:756
#12 0xc02895ef in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi =
51676, tf_esi = 1816, tf_ebp = 264, tf_isp = -1069719596,
tf_ebx = 264, tf_edx = 980, tf_ecx = 6930, tf_eax = 0, tf_trapno = 12,
tf_err = 4, tf_eip = 4773, tf_cs = 49152,
tf_eflags = 721478, tf_esp = 4000, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:426
#13 0x12a5 in ?? ()
Cannot access memory at address 0x108.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: ucred for threads
On Thu, 7 Feb 2002, John Baldwin wrote: This code is not safe on SMP non-i386 machines (i.e. ia64, sparc64, alpha, and possibly p3 and later i386's) because the p_ucred value you read could easily be a stale value, thus rendering the test invalid. You need the lock for the compare. Conceptually minimizing the crfree's isn't bad I guess. However, the td_ucred pointer should nto be read if the thread is not in the kernel, and having it set to NULL when we leave the kernel provides a conveninet way of ensuring this doesn't happen since we will panic if we do. if the ucred is stale or not is completely unimportant. if you wish to ensure that all your threads get the new ID that you are setting then you need to synchronise them at the program level to ensure teh order in which they enter the kernel on their next system calls. There is no point is sychronising with locks because the threads in question may have run in any order anyhow. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Wasn't Eric Melville going to fix this by turning the normal system components into packages? 8-) 8-). Yeah, I'm just rather busy between work and school these days. I'm giving a little presentation on this at BSDCon, hopefully I can rope some more folks in to the project. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
John Baldwin wrote: No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed on some other processor by another thread from this processor? I saw your response to Julian... I understand the concern, but I think it's unfounded. Let me explain. Without a lock you don't have a guarantee that that other processor's writes are visible to you. We really don't want to be using stale credentials for syscalls given the past history of race conditions involving credentials. If in the future it is deemed that getting a stale cred is an acceptable race, then this can be optimized then, but for now we had better get it right. There's stale and there's Stale. I thnk stale is OK. Here's how I see it: If there's a race between changing and using a cred in kernel space, it can only come about because of a similar race in user space. This means that if I change from cred A to cred B, there's no difference in the closure between losing the race in the kernel (and getting a stale value) and losing the race in user space (and getting a stale value). Basically, if it's an issue, then user level primitives have to be used to protect the request for the credential change. Maybe a picture would be better: Threads Creds 1 2 A B case i: setuid x--x create x case ii: setuid create x - user race lost x--x case iii: setuid x--x create x - stale FreeBSD doesn't run on just the i386 anymore, we have Alpha, ia64, and sparc64 SMP machines to deal with as well. I understand; I'm very noisy about this point myself, e.g. the recent binutils breakage that made Alpha not build at all. However, I'm not convinced that it's possible to have the kernel race be present, without a corresponding user race, which means protecting against case iii doe nothing for you, if you can still get the inversion from case ii. If, on the other hand, you have user space synchornization that guards against case ii, then the fact that the synchornization operates across the same barrier as the credential change call means that the you also protect against case iii. Are there any obvious cases that I'm just not seeing here where a case iii is possible without a case ii? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
list To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: time breakage.
In message [EMAIL PROTECTED], Ju lian Elischer writes: phk, is this you? /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned Yes, that was me, seems like I did my buildworld test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
