Re: m4 still broken on gcc platforms
On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote: Hi, I am still seeing this with arm/power/sparc/mips. Can somene please fix it? Did this get fixed because I still see it on -current while trying to build armeb for the AVILA and CAMBRIA boards. Regards John -- John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za === usr.bin/m4/tests (all) cc1: warnings being treated as errors /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c: In function 'm4errx': /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c:268: warning: declaration of 'eval' shadows a global declaration /scratch/tmp/bz/head.svn/usr.bin/m4/extern.h:40: warning: shadowed declaration is here --- misc.o --- *** [misc.o] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 cc1: warnings being treated as errors /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_remove': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:123: warning: cast discards qualifiers from pointer target type /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_find': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:144: warning: cast discards qualifiers from pointer target type /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_next': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:183: warning: cast discards qualifiers from pointer target type --- ohash.o --- *** [ohash.o] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 --- all_subdir_m4 --- *** [all_subdir_m4] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin === usr.bin/mail (all) ? Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: m4 still broken on gcc platforms
On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote: On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote: On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote: Hi, I am still seeing this with arm/power/sparc/mips. Can somene please fix it? Did this get fixed because I still see it on -current while trying to build armeb for the AVILA and CAMBRIA boards. It has ben fixed last week It is still broken for me. Maybe it is my environment. The last time I have updated my source tree was about 2 weeks ago and with that I could build working AVILA and CAMBRIA boards. I have updated now so that I could get the interrupt fixes that Ian committed a few hours ago. My tree is at svn 269656. The machine I am building on is running 10-stable from around 30 March, if that makes a difference. Regards John -- John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [ANNOUNCEMENT] pkg 1.3.0 out!
On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote: On 07/24/14 23:56, John Hay wrote: On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: Hi all, I'm very please to announce the release of pkg 1.3.0 This version is the result of almost 9 month of hard work ... Thank you to all contributors: Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, Vsevolod Stakhov, Xin Li, coctic Regards, Bapt on behalf of the pkg@ Version 1.3 does better on armeb. It does not crash while installing itself, but still complains and get the architecture wrong: [snip] Would it make sense to get the architecture from the kernel, with a manual override for cross-installs? It seems like that would prevent cases like this permanently. If a file has to be checked, what about the same mechanism that file (libmagic) use? It seems to get it right: root@cambria-build # file /bin/sh /bin/sh: ELF 32-bit MSB executable, ARM, EABI4 version 1 (SYSV), dynamically linked (uses shared libs), FreeBSD-style, for FreeBSD 11.0 (1100028), stripped John -- John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [ANNOUNCEMENT] pkg 1.3.0 out!
On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote:
Hi all,
I'm very please to announce the release of pkg 1.3.0
This version is the result of almost 9 month of hard work
...
Thank you to all contributors:
Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis,
Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie
Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold,
Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas
Szalay,
Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya,
Vsevolod Stakhov, Xin Li, coctic
Regards,
Bapt on behalf of the pkg@
Version 1.3 does better on armeb. It does not crash while installing
itself, but still complains and get the architecture wrong:
root@cambria-build:/usr/ports/ports-mgmt/pkg # make install
=== Installing for pkg-1.3.0
=== Checking if ports-mgmt/pkg already installed
pkg-static: failed to find the version elf note
=== Registering installation for pkg-1.3.0
pkg-static: failed to find the version elf note
pkg-static: failed to find the version elf note
If you are upgrading from the old package format, first run:
# pkg2ng
root@cambria-build:/usr/ports/ports-mgmt/pkg # pkg info pkg
pkg: failed to find the version elf note
pkg-1.3.0
Name : pkg
Version: 1.3.0
Installed on : Fri Jul 25 06:36:42 UTC 2014
Origin : ports-mgmt/pkg
Architecture : ??
Prefix : /usr/local
Categories : ports-mgmt
Licenses : BSD2CLAUSE
Maintainer : port...@freebsd.org
WWW: http://wiki.freebsd.org/pkgng
Comment: Package manager
Flat size : 7.14MiB
Description:
Package management tool
WWW: http://wiki.freebsd.org/pkgng
root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -a
FreeBSD cambria-build 11.0-CURRENT FreeBSD 11.0-CURRENT #13 r269057M: Thu Jul
24 15:54:38 SAST 2014
j...@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/CAMBRIA
arm
root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -p
armeb
root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -m
arm
root@cambria-build:/usr/ports/ports-mgmt/pkg
###
On the previous pkg, I used a small crow-bar patch (attached) then it did
install properly and its architecture looked like this:
###
% pkg info pkg
pkg-1.2.7_3
Name : pkg
Version: 1.2.7_3
Installed on : Thu Jul 17 15:15:05 SAST 2014
Origin : ports-mgmt/pkg
Architecture : freebsd:11:arm:32:eb:eabi:softfp
Prefix : /usr/local
Categories : ports-mgmt
Licenses : BSD2CLAUSE
Maintainer : port...@freebsd.org
WWW: http://wiki.freebsd.org/pkgng
Comment: Package manager
Shared Libs required:
libpkg.so.1
Flat size : 6.48MiB
Description:
Package management tool
WWW: http://wiki.freebsd.org/pkgng
###
Regards
John
--
John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za
--- libpkg/pkg_elf.c.orig 2014-03-15 13:15:46.0 +
+++ libpkg/pkg_elf.c2014-06-23 17:41:35.0 +
@@ -636,6 +636,12 @@
int ret = EPKG_OK;
int i;
const char *arch, *abi, *endian_corres_str, *wordsize_corres_str, *fpu;
+ const char *path;
+ char localname[] = freebsd;
+
+ path = getenv(ABI_FILE);
+ if (path == NULL)
+ path = _PATH_BSHELL;
if (elf_version(EV_CURRENT) == EV_NONE) {
pkg_emit_error(ELF library initialization failed: %s,
@@ -643,7 +649,7 @@
return (EPKG_FATAL);
}
- if ((fd = open(_PATH_BSHELL, O_RDONLY)) 0) {
+ if ((fd = open(path, O_RDONLY)) 0) {
pkg_emit_errno(open, _PATH_BSHELL);
snprintf(dest, sz, %s, unknown);
return (EPKG_FATAL);
@@ -687,6 +693,7 @@
break;
src += note.n_namesz + note.n_descsz;
}
+#if 0
if ((uintptr_t)src = ((uintptr_t)data-d_buf + data-d_size)) {
ret = EPKG_FATAL;
pkg_emit_error(failed to find the version elf note);
@@ -698,7 +705,10 @@
version = be32dec(src);
else
version = le32dec(src);
-
+#else
+ osname = localname;
+ version = 11 * 10;
+#endif
for (i = 0; osname[i] != '\0'; i++)
osname[i] = (char)tolower(osname[i]);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPv6 accept_rtadv + bfe0
On Sat, Oct 22, 2011 at 04:13:36PM +0900, Hiroki Sato wrote: Doug Barton do...@freebsd.org wrote in 4ea23c08.6060...@freebsd.org: do On 10/19/2011 00:29, Hiroki Sato wrote: do Mattia Rossi mro...@swin.edu.au wrote doin 4e9dfe11.2070...@swin.edu.au: do do mr So the _ipv6 bit doesn't take care of passing inet6 to ifconfig do mr automatically? do do No. You always need to add the inet6 keyword wherever needed. do do That seems redundant, and contrary to how the IPv4 equivalents work. And do obviously it's confusing to users. From what I can see looking at some do 7.x and 8.x systems it also seems to be a POLA violation. do do Perhaps this is something that you should reconsider? I am still thinking that omitting an address family keyword before an address is a bad practice. Omitting inet keyword in ifconfig_IF and doing in ifconfing_IF_AF are different. The former one uses ifconfig(8)'s default AF, and bz's experiments of noinet/noinet6 environment showed it was problematic. For the latter a keyword has to be automatically prepended in the rc.d scripts if we want to do so. For IPv6, having a non-null $ifconfig_IF_ipv6 means the interface is IPv6-capable and doesn't always involve address configuration (e.g. ifconfig_IF_ipv6=up is valid). So, automatic prepending of inet6 breaks this. Thus, both have a bad side effect. And I want to make ifconfig accept a command line for v4-v6 and/or v6-v4 tunneling as a p2p link like inet 10.1.1.1 2001:db8::1 for a specific type of interfaces in the future. I am not sure if it will happen actually, but omitting an AF keyword and/or automatic prepending of the keyword make things difficult. I can maybe just say, I have now upgraded various machines from 7.x or 8.x to 9 and even though I have read the rc.conf manual I keep tripping on the new IPv6 rc stuff. Various being client, server and router / firewall. It looks like ipv6_prefix_IF now needs an ifconfig_IF_ipv6 = inet6 auto_linklocal otherwise it is ignored. In the rc.conf man page, in the ifconfig_interface_ipv6 section, it is suggested to use ifconfig_interface_aliasn for aliases, but somewhere else it says that that _aliasn is deprecated. What would be nice is something like the ipv4_addrs_IF= variable. The last paragraph in ifconfig_interface_ipv6, about inet6 accept_rtadv should probably be closer to the begining, with some added sentence to make it clear that it is probably what the normal client machine needs. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
freebsd-9.0 smartmontools and ada devices
Hi Guys, I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using a GENERIC kernel. I have installed the smartmontools-5.41_3 package from a mirror and found that smartmontools does not like the ada devices anymore. Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. There an older smartmontools (5.40) worked without a problem on the ada devices. The output of smartctl looks like this: # dolphin# smartctl -a /dev/ada0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ada0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary # Has anybody seen it? John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-9.0 smartmontools and ada devices
On Tue, Oct 18, 2011 at 09:39:24AM +0200, John Hay wrote: Hi Guys, I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using a GENERIC kernel. I have installed the smartmontools-5.41_3 package from a mirror and found that smartmontools does not like the ada devices anymore. Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. There an older smartmontools (5.40) worked without a problem on the ada devices. The output of smartctl looks like this: # dolphin# smartctl -a /dev/ada0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ada0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary # Just to follow up on myself. :-( I have build smartmontools from ports and even though it is the same version, it works. So for me the package amd64/packages-9-current/All/smartmontools-5.41_3.tbz did not work, but the port does. John ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gptboot rewrite, bootonce, etc.
On Mon, Sep 20, 2010 at 03:59:20PM +0300, Andriy Gapon wrote: on 20/09/2010 15:47 Pawel Jakub Dawidek said the following: No, it doesn't. ZFS works a bit differently. ZFS operate on pools, not really on partitions. One ZFS file system can span multiple disks/partitions. I'm not yet sure how to implement it, so it is intuitive, but I also haven't spend much time thinking about it. We needed UFS and that is what I implemented. It took me much more time than I expected anyway:) Maybe reserve some area inside zfs boot2 and put relevant information there. Similarly to how boot0cfg modifies data within boot0. The information could include nextboot-pool and nextboot-fs. nextboot-fs sounds nice. I use the bootfs property of zpool and it would be nice if one can override it from the boot2 commandline. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_enable
as a special AF after I added AF-specific $ifconfig_* knobs, rc.d/netoptions changes, and so on. And, well, please let me suggest something for the further discussion here. Whether we have $ipv6_enable or not, whether we enable $ipv6_enable by default or not, and whether receiving RA by default or not, are separated topics from each other. So, I would like everyone's opinions for the following points separately: 1. Do we need a knob to disable IPv6? If so, which in the following is expected for that knob? 1-a) Disable ifconfig_IF_ipv6 processing only. This means people can still do manual configuration for IPv6. 1-b) Disable IPv6 functionlity completely. 2. If we have a knob described in 1, what should be the default value? 3. Do we go for accept RAs by default? We can break down this in the following way related to 2: 3-a) Enable IPv6 functionality and accept RAs by default. 3-b) Enable IPv6 functionality and not accept RAs by default 3-c) Disable IPv6 functionality by default and accept RAs if one enables IPv6 in rc.conf. 3-d) Disable IPv6 functionality by default and not accept RAs even if one enables IPv6 in rc.conf. My answers for them are: 1. No objection for 1-a, but if so the name $ipv6_enable is wrong to me. If people needs 1-b, it should be $ipv6_enable. I have no strong opinion on whether we have one of or both of them. If we can reach a consensus to have 1-b, I am ready to implement the necessary changes. 2. I am for enabled by default regardless of 1-a or 1-b. 3. I am for 3-b. These questions actually start more questions for me. :-) Maybe we should also think from the user perspective and list a few use cases and what a user need to put in rc.conf to make that work? Your normal desktop/notebook user on a ipv6 radv network, what does he need to do to have his machine ipv6 usable? A network server that does not accept radv, what should its ipv6 config in rc.conf look like? What about a server that accept radv (so that it can get router info) and have fixed addresses for it services? A router kind of box, what should it look like? Maybe by stating these, and other, use-cases, it will make it easier to work back to what should happen under the hood? :-) And maybe if we can document this well in rc.conf(5) for instance, it would make it easier for people to start with ipv6. BTW I have been running an ipv6 network for 10+ years, but the SLAAC acronym is still strange to me. :-) BTW2 RA on the network has bitten us a few times on the network, but it always turned out to be innocent mistakes. We have also had rogue DHCP servers, which also was innocent mistakes, so I doubt if just moving from RA to DHCP6 will be the answer. :-) John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
new kernel and old programs - bad system call
Hi, Is it ok to run a new kernel (after the statfs changes) and older programs? I thought so from what i gathered out of the commit messages, but my test box doesn't like it at all... Well except if something else broke stuff: ## ... Mounting root from ufs:/dev/da0s1a pid 50 (sh), uid 0: exited on signal 12 Enter full pathname of shell or RETURN for /bin/sh: # ls pid 56 (ls), uid 0: exited on signal 12 Bad system call # ## I thought that there might have been some leftover in my kernel compile directory to spoil things, so I did a make clean in the kernel directory and tried again, but it still does the same. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new kernel and old programs - bad system call
On Fri, Nov 14, 2003 at 06:38:28AM +1100, Bruce Evans wrote: On Thu, 13 Nov 2003, John Hay wrote: Is it ok to run a new kernel (after the statfs changes) and older programs? I thought so from what i gathered out of the commit messages, but my test box doesn't like it at all... Well except if something else broke stuff: I have no problems with a current kernel and an old world. ## ... Mounting root from ufs:/dev/da0s1a pid 50 (sh), uid 0: exited on signal 12 Enter full pathname of shell or RETURN for /bin/sh: # ls pid 56 (ls), uid 0: exited on signal 12 Bad system call # ## Maybe you don't have old programs. Unfortunately, even /bin/sh is affected by the changes (it has a reference to fstatfs). I'm pretty sure it is old binaries because they work with my old kernel: beast# ls -l /bin/*sh* /boot/kernel.work/kernel /boot/kernel/kernel -r-xr-xr-x 2 root wheel 879252 Nov 11 14:52 /bin/csh -r-xr-xr-x 1 root wheel 751752 Nov 11 14:52 /bin/sh -r-xr-xr-x 2 root wheel 879252 Nov 11 14:52 /bin/tcsh -r-xr-xr-x 1 root wheel 2673454 Nov 3 09:17 /boot/kernel.work/kernel -r-xr-xr-x 1 root wheel 2758305 Nov 13 09:01 /boot/kernel/kernel The binaries work just fine with kernel.work but not with kernel. Maybe I should try a few other things, like a UP kernel. Luckily the old reboot still works on the new kernel. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps there is a BIOS option to set the interrupt model to APIC rather than PIC that might fix the ACPI case. Ok, I opened the machine this morning and it does have an AGP slot. I also had a look in the BIOS setup, but didn't see anything to change the interrupt model. The closest I saw was: MPS 1.4 Support - Enabled/Disabled (Enabled) PCI 2.1 Support - Enabled/disabled (Enabled) PNP OS Installed - No/Yes (No) I built a new kernel with your mptable changes included and with acpi enabled, it would panic, but the onboard scsi interrupt doesn't work, so you don't get very far. With acpi disabled, it seems to work fine, although I haven't done much yet. So it looks like I'm up and running again, thanks. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
Oops, I missed a not. On Wed, Nov 12, 2003 at 09:01:25AM +0200, John Hay wrote: Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about. I'll commit a fix. Note that your system isn't going to work with ACPI. Perhaps there is a BIOS option to set the interrupt model to APIC rather than PIC that might fix the ACPI case. Ok, I opened the machine this morning and it does have an AGP slot. I also had a look in the BIOS setup, but didn't see anything to change the interrupt model. The closest I saw was: MPS 1.4 Support - Enabled/Disabled (Enabled) PCI 2.1 Support - Enabled/disabled (Enabled) PNP OS Installed - No/Yes (No) I built a new kernel with your mptable changes included and with acpi enabled, it would panic, but the onboard scsi interrupt doesn't work, ^^^ not so you don't get very far. With acpi disabled, it seems to work fine, although I haven't done much yet. So it looks like I'm up and running again, thanks. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic
when booting:
...
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x633 Stepping = 3
Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory = 134205440 (127 MB)
avail memory = 125018112 (119 MB)
MPTable: OEM0 PROD
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 1
cpu1 (AP): APIC ID: 0
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
acpi0: ASUS P2L97-DS on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: Power Button (fixed)
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 4 INTD is routed to irq 5
pcib0: slot 6 INTA is routed to irq 5
pcib0: slot 10 INTA is routed to irq 12
pcib0: slot 11 INTA is routed to irq 10
pcib0: slot 12 INTA is routed to irq 11
panic: probing for non-PCI bus
cpuid = 0;
Uptime: 1s
Shutting down ACPI
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Can you provide a copy of your mptable?
Wait, you have ACPI enabled, but ACPI didn't enumerate your CPUs? Umm, can
you provide an acpdump -t from your machine? Also, can you try hacking
mptable_pci_probe_table() in mptable.c to print out pci0 and bus at the start
of the function? Thanks.
Ok, acpidump -t output at the end.
This is with the printf added.
###
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x633 Stepping = 3
Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory = 134205440 (127 MB)
avail memory = 125018112 (119 MB)
MPTable: OEM0 PROD
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 1
cpu1 (AP): APIC ID: 0
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
acpi0: ASUS P2L97-DS on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: Power Button (fixed)
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 4 INTD is routed to irq 5
pcib0: slot 6 INTA is routed to irq 5
pcib0: slot 10 INTA is routed to irq 12
pcib0: slot 11 INTA is routed to irq 10
pcib0: slot 12 INTA is routed to irq 11
mptable_pci_probe_table: pci0 0, bus 1
panic: probing for non-PCI bus
cpuid = 0;
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db
###
I tried without acpi and it panic in the same way. I see that this time
the printf happened twice:
##
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x633 Stepping = 3
Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory = 134205440 (127 MB)
avail memory = 125026304 (119 MB)
MPTable: OEM0 PROD
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 1
cpu1 (AP): APIC ID: 0
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
mptable_pci_probe_table: pci0 0, bus 0
pcib0: MPTable Host-PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pcib0: slot 4 INTD routed to irq 19
pcib0: slot 6 INTA routed to irq 19
pcib0: slot 10 INTA routed to irq 18
pcib0: slot 11 INTA routed to irq 17
pcib0: slot 12 INTA routed to irq 16
mptable_pci_probe_table: pci0 0, bus 1
panic: probing for non-PCI bus
cpuid = 0;
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db
##
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
/*
RSD PTR: OEM=ASUS, ACPI_Rev=1.0x (0)
RSDT=0x07ffd000, cksum=143
*/
/*
RSDT: Length=44, Revision=1, Checksum=160,
OEMID=ASUS, OEM Table ID=P2L97-DS, OEM Revision=0x58582e31,
Creator ID=ASUS, Creator Revision=0x31303030
Entries={ 0x07ffd080, 0x07ffd040 }
*/
/*
FADT: FACS=0x7fff000, DSDT=0x7ffd100
INT_MODEL=PIC
Preferred_PM_Profile=Unspecified (0)
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xa1, ACPI_DISABLE=0xa0, S4BIOS_REQ=0x0
PSTATE_CNT=0x0
PM1a_EVT_BLK
Re: panic: probing for non-PCI bus
On Tue, Nov 11, 2003 at 03:28:25PM -0500, John Baldwin wrote: On 11-Nov-2003 John Hay wrote: Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: ... CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134205440 (127 MB) avail memory = 125018112 (119 MB) MPTable: OEM0 PROD FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard Pentium Pro MTRR support enabled acpi0: ASUS P2L97-DS on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 5 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 12 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 panic: probing for non-PCI bus cpuid = 0; Uptime: 1s Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Can you provide a copy of your mptable? Wait, you have ACPI enabled, but ACPI didn't enumerate your CPUs? Umm, can you provide an acpdump -t from your machine? Also, can you try hacking mptable_pci_probe_table() in mptable.c to print out pci0 and bus at the start of the function? Thanks. Ok, acpidump -t output at the end. Oof, no MADT table. Your BIOS sucks. :-P Don't use ACPI because PCI interrupts aren't going to work otherwise. Does this system have an AGP slot? Also, do you have a dmesg from before? Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] OK unload kernel OK boot kernel.work /boot/kernel.work/kernel text=0x1fc54c data=0x24d6c+0x464b4 syms=[0x4+0x2c720+0x4+0x36d6a] /boot/kernel.work/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573] /boot/kernel.work/if_fxp.ko text=0x7840 data=0x1014+0xc syms=[0x4+0xcb0+0x4+0xdb2] loading required module 'miibus' /boot/kernel.work/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240] /boot/kernel.work/usb.ko text=0x2036c data=0xc0c+0x148 syms=[0x4+0x2bf0+0x4+0x331f] /boot/kernel.work/acpi.ko text=0x3b718 data=0x16c4+0xee8 syms=[0x4+0x5b90+0x4+0x7944] Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #49: Mon Nov 3 09:16:49 SAST 2003 [EMAIL PROTECTED]:/b/src/sys/i386/compile/BEAST Preloaded elf kernel /boot/kernel.work/kernel at 0xc076e000. Preloaded elf module /boot/kernel.work/if_vlan.ko at 0xc076e224. Preloaded elf module /boot/kernel.work/if_fxp.ko at 0xc076e2d8. Preloaded elf module /boot/kernel.work/miibus.ko at 0xc076e388. Preloaded elf module /boot/kernel.work/usb.ko at 0xc076e438. Preloaded elf module /boot/kernel.work/acpi.ko at 0xc076e4e8. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134205440 (127 MB) avail memory = 125018112 (119 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P2L97-DS on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 18 - irq 5 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 16 - irq 11 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 pci0: mass storage, ATA at device 4.1
Re: panic: probing for non-PCI bus
acpi0: ASUS P2L97-DS on motherboard Here's the mobo model. you might check for a BIOS update... Nope, I'm running the latest - 1008. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
diskless panic with new interrupt code
Hi, My old diskless dual Pentium I 100MHz system does not like the latest code. I use etherboot to boot it. I have tried both an UP and SMP kernel but it panic in the same way. Looking at the low address values, it looks as if it happens very early. Maybe something depends on the loader initializing things nowadays? A kernel of about 2 weeks ago did boot without a problem, even an SMP one. On bootup this is what I see: # WARNING: loader(8) metadata is missing! instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: probing for non-PCI bus
Hi, Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS 640kB/130036kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sun Nov 2 14:16:55 SAST 2003) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x23372c data=0x27fcc+0x47494 syms=[0x4+0x31690+0x4+0x3de08] /boot/kernel/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573] /boot/kernel/if_fxp.ko text=0x77c0 data=0xfd4+0xc syms=[0x4+0xc50+0x4+0xceb] loading required module 'miibus' /boot/kernel/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240] /boot/kernel/usb.ko text=0x201e8 data=0xb4c+0x148 syms=[0x4+0x2ad0+0x4+0x30bb] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #50: Mon Nov 10 17:51:13 SAST 2003 [EMAIL PROTECTED]:/b/src/sys/i386/compile/BEAST Preloaded elf kernel /boot/kernel/kernel at 0xc0768000. Preloaded elf module /boot/kernel/if_vlan.ko at 0xc076821c. Preloaded elf module /boot/kernel/if_fxp.ko at 0xc07682c8. Preloaded elf module /boot/kernel/miibus.ko at 0xc0768374. Preloaded elf module /boot/kernel/usb.ko at 0xc0768420. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134205440 (127 MB) avail memory = 125018112 (119 MB) MPTable: OEM0 PROD FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard Pentium Pro MTRR support enabled acpi0: ASUS P2L97-DS on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 5 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 12 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 panic: probing for non-PCI bus cpuid = 0; Uptime: 1s Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) Actually, can you try spurious.patch (same URL directory) instead and see if that is sufficient to fix it? Nope, this behaves the same as without the patches, ie. I have to type continue. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS 640kB/130036kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sun Nov 2 14:16:55 SAST 2003) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x23372c data=0x27fcc+0x47494 syms=[0x4+0x31690+0x4+0x3de08] /boot/kernel/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573] /boot/kernel/if_fxp.ko text=0x77c0 data=0xfd4+0xc syms=[0x4+0xc50+0x4+0xceb] loading required module 'miibus' /boot/kernel/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240] /boot/kernel/usb.ko text=0x201e8 data=0xb4c+0x148 syms=[0x4+0x2ad0+0x4+0x30bb] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #50: Mon Nov 10 17:51:13 SAST 2003 [EMAIL PROTECTED]:/b/src/sys/i386/compile/BEAST Preloaded elf kernel /boot/kernel/kernel at 0xc0768000. Preloaded elf module /boot/kernel/if_vlan.ko at 0xc076821c. Preloaded elf module /boot/kernel/if_fxp.ko at 0xc07682c8. Preloaded elf module /boot/kernel/miibus.ko at 0xc0768374. Preloaded elf module /boot/kernel/usb.ko at 0xc0768420. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134205440 (127 MB) avail memory = 125018112 (119 MB) MPTable: OEM0 PROD FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard Pentium Pro MTRR support enabled acpi0: ASUS P2L97-DS on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 5 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 12 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 panic: probing for non-PCI bus cpuid = 0; Uptime: 1s Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Can you provide a copy of your mptable? Yes, here is the output of mptable -verbose on a kernel built on Nov 3. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] === MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, NOT found searching CMOS 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f MP FPS found in BIOS @ physical addr: 0x000f6e30 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000f6e30 signature:'_MP_' length: 16 bytes version: 1.4 checksum: 0x05 mode: Virtual Wire --- MP Config Table Header: physical address: 0x000f6a22 signature:'PCMP' base table length:252 version: 1.4 checksum: 0xf9 OEM ID: 'OEM0' Product ID: 'PROD' OEM table pointer:0x OEM table size: 0 entry count: 23 local APIC address: 0xfee0 extended table length:124 extended table checksum: 179 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model StepFlags 1 0x11BSP, usable 6 3 3 0x80fbff 0 0x11AP, usable 6 3 3 0x80fbff -- Bus:Bus ID Type 0 PCI 1 ISA -- I/O APICs: APIC ID Version State Address 2 0x11
panic: mutex rtentry not owned at /usr/src/sys/net/route.c:225
I had this panic on a 1 day old kernel. route.c is rev 1.87, nd6.c is rev 1.31 and ip6_output.c is at rev 1.58. ## angel:/usr/obj/usr/src/sys/ANGEL # gdb -k kernel.debug /var/crash/vmcore.10 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd... panic: mutex rtentry not owned at /usr/src/sys/net/route.c:225 panic messages: --- panic: mutex rtentry not owned at /usr/src/sys/net/route.c:225 syncing disks, buffers remaining... 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 2191 giving up on 1977 buffers Uptime: 1d13h57m25s Dumping 250 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /boot/kernel/if_xl.ko...done. ... #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0482757 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0482a18 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc047ad51 in _mtx_assert (m=0xc2a0da90, what=0, file=0xc05b9e4f /usr/src/sys/net/route.c, line=225) at /usr/src/sys/kern/kern_mutex.c:855 #4 0xc04e0598 in rtfree (rt=0xc2a0da00) at /usr/src/sys/net/route.c:225 #5 0xc0518291 in nd6_output (ifp=0xc2988800, origifp=0xc2988800, m0=0xc12ae700, dst=0xc2a240dc, rt0=0xc361ca00) at /usr/src/sys/netinet6/nd6.c:1917 #6 0xc0513ad9 in ip6_output (m0=0x0, opt=0x0, ro=0xc2a64120, flags=0, im6o=0x0, ifpp=0x0, inp=0xc2a640e4) at /usr/src/sys/netinet6/ip6_output.c:961 #7 0xc04fa5b2 in tcp_output (tp=0xc2a9a42c) at /usr/src/sys/netinet/tcp_output.c:883 #8 0xc04fe40d in tcp_timer_delack (xtp=0xc2a9a42c) at /usr/src/sys/netinet/tcp_timer.c:198 #9 0xc048fc66 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:225 #10 0xc04728fb in ithread_loop (arg=0xc1298d00) at /usr/src/sys/kern/kern_intr.c:534 #11 0xc0471c9b in fork_exit (callout=0xc04727d0 ithread_loop, arg=0xc1298d00, frame=0xcd77bd48) at /usr/src/sys/kern/kern_fork.c:796 (kgdb) ## John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel maybe borked...
On Sat, Oct 18, 2003 at 03:48:49PM +0200, Poul-Henning Kamp wrote: I'm chasing a problem which indicates that I may have borked the kernel with one of my last commits. I'm hunting it right now. So you don't mean just compile errors like this, but real things like turning over the fish bowl when booting? cc -O -pipe -march=pentium -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/dev/raidframe/rf_freebsdkintf.c /usr/src/sys/dev/raidframe/rf_freebsdkintf.c: In function `rf_DispatchKernelIO': /usr/src/sys/dev/raidframe/rf_freebsdkintf.c:1547: error: structure has no member named `b_io' /usr/src/sys/dev/raidframe/rf_freebsdkintf.c:1547: error: structure has no member named `b_io' *** Error code 1 Stop in /usr/src/sys/modules/raidframe. *** Error code 1 Stop in /usr/src/sys/modules. ## John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_map_wire: lookup failed
The latest development source of ntpd started to use setrlimit() before using mlockall(). This combination proves fatal on -current. The code in ntpd/ntpd.c looks like this: Ok, I found an easier way to provoke the panic. Just compile the following program like this: if (mlockall(MCL_CURRENT|MCL_FUTURE) 0) perror(mlockall()); Did you tested it on a recent -current? It is supposed to be fixed (since a day or two, I think). Nope it is still not fixed. I have tried again just now and it still throw a panic on both UP and SMP. Try for yourself if you are brave. :-))) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_map_wire: lookup failed
The latest development source of ntpd started to use setrlimit() before
using mlockall(). This combination proves fatal on -current. The code
in ntpd/ntpd.c looks like this:
Ok, I found an easier way to provoke the panic. Just compile the following
program like this:
cc -Wall -O -o vm -lcrypto vm.c
and run as root. The program itself does not use the crypto, but it is
needed to provoke the panic.
# vm.c ##
#include stdio.h
#include sys/mman.h
int
main(int argc, char **argv)
{
/*
* lock the process into memory
*/
if (mlockall(MCL_CURRENT|MCL_FUTURE) 0)
perror(mlockall());
return 0;
}
###
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vm_map_wire: lookup failed
Hi,
The latest development source of ntpd started to use setrlimit() before
using mlockall(). This combination proves fatal on -current. The code
in ntpd/ntpd.c looks like this:
###
#if defined(HAVE_MLOCKALL) defined(MCL_CURRENT) defined(MCL_FUTURE)
# ifdef HAVE_SETRLIMIT
/*
* Set the stack limit to something smaller, so that we don't lock a lot
* of unused stack memory.
*/
{
struct rlimit rl;
if (getrlimit(RLIMIT_STACK, rl) != -1
(rl.rlim_cur = 20 * 4096) rl.rlim_max)
{
if (setrlimit(RLIMIT_STACK, rl) == -1)
{
msyslog(LOG_ERR,
Cannot adjust stack limit for mlockall: %m);
}
}
}
# endif /* HAVE_SETRLIMIT */
/*
* lock the process into memory
*/
if (mlockall(MCL_CURRENT|MCL_FUTURE) 0)
msyslog(LOG_ERR, mlockall(): %m);
#else /* not (HAVE_MLOCKALL MCL_CURRENT MCL_FUTURE) */
###
The panic message is:
panic: vm_map_wire: lookup failed
and a backtrace looks like this:
##
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc047ff07 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04801c8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc055a714 in vm_map_wire (map=0xc0e0c6e4, start=0, end=3216949248,
flags=3) at /usr/src/sys/vm/vm_map.c:1919
#4 0xc055d113 in mlockall (td=0x0, uap=0xc6361d14)
at /usr/src/sys/vm/vm_map.h:201
#5 0xc0591efb in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077936788, tf_esi = 2, tf_ebp =
-1077936904, tf_isp = -969532044, tf_ebx = -1077936944, tf_edx = 0, tf_ecx = 9, tf_eax
= 324, tf_trapno = 12, tf_err = 2, tf_eip = 673338079, tf_cs = 31, tf_eflags = 658,
tf_esp = -1077937108, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1006
#6 0xc0584c5d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb)
##
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass panic when connecting camera
I have decided to upgrade my home box from a March -current to the latest
stuff and now when I connect my HP850 digital camera to the usb port, it
panics the machine. I got a dump and according to the instruction pointer
and kldstat, it must be inside the umass, but I think something confuse
gdb a little because that doesn't show up in the backtrace or maybe it is
just me not knowing how to convince gdb to tell me:
###
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0729c26
stack pointer = 0x10:0xc6317cbc
frame pointer = 0x10:0xc6317cd0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (swi8: tty:sio clock)
trap number = 12
panic: page fault
Ok, it seems that when plugging in a device, the contacts can have some
noise and you get a disconnect inbetween. If that happens before the
timeout() in umass, bad things can happen. I have added an untimeout()
and now everything seems ok. Patch at the end.
Any comments from people a little more knowledgable in the umass/usb
area?
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
Index: umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.91
diff -u -r1.91 umass.c
--- umass.c 20 Sep 2003 08:18:16 - 1.91
+++ umass.c 7 Oct 2003 16:35:45 -
@@ -396,6 +396,7 @@
usbd_device_handle sc_udev;/* USB device */
struct cam_sim *umass_sim; /* SCSI Interface Module */
+ struct callout_handle rescanh;/* timeout handle */
unsigned char flags; /* various device flags */
# define UMASS_FLAGS_GONE 0x01/* devices is no more */
@@ -2165,7 +2166,7 @@
/* XXX This will bomb if the driver is unloaded between attach
* and execution of umass_cam_rescan.
*/
- timeout(umass_cam_rescan, sc, MS_TO_TICKS(200));
+ sc-rescanh = timeout(umass_cam_rescan, sc, MS_TO_TICKS(200));
}
return(0); /* always succesfull */
@@ -2179,6 +2180,7 @@
umass_cam_detach_sim(struct umass_softc *sc)
{
if (sc-umass_sim) {
+ untimeout(umass_cam_rescan, sc, sc-rescanh);
if (xpt_bus_deregister(cam_sim_path(sc-umass_sim)))
cam_sim_free(sc-umass_sim, /*free_devq*/TRUE);
else
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass panic when connecting camera
On Tue, Oct 07, 2003 at 07:11:10PM +0100, Bruce M Simpson wrote: On Tue, Oct 07, 2003 at 08:02:02PM +0200, John Hay wrote: Any comments from people a little more knowledgable in the umass/usb area? I don't know about USB specifically, but I thought timeout() et al were to be deprecated in favour of callout*() ? Well I just wanted to get my device working again without changing the code too much, so I added an untimeout() for the existing timeout(). The usb code is also shared with the other *BSD groups. Looking at the rest of the usb files, I see that they do use usb_callout*(), so one can probably convert umass to it. The man page for (un)timeout and callout* is interesting because it does say that timeout() is the old style and new code should use the callout_* functions but a little later it also says The functions callout_init(), callout_stop() and callout_reset() are low- level routines for clients who wish to allocate their own callout struc- tures. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth patch
Hi Maksim,
I have prepared Bluetooth mega patch for FreeBSD source tree. This patch
updates FreeBSD sources to the most recent snapshot. The patch is quite
extensive - it adds two new libraries (libbluetooth and libsdp) as well
as puts some files into /etc/bluetooth and modifies quite a few other files.
I also have modified Makefile's to add new libraries and usr.{s}bin/bluetooth
to the build.
I've sent it to Julian and Ruslan, but they do not have free time to look
at it. If anyone wants to review the patch please do so and let me know if
i missed/forget anything.
The patch could be downloaded from
http://www.geocities.com/m_evmenkin/patch/bluetooth20030914.diff.gz
I had a look at the patch and here is my comments. I haven't tried it
yet, but I did try your latest snapshot. I haven't looked at the man
page markup, someone more knowledgable can do that, or it can be
committed and then Ruslan can have a look at it when he gets time.
There are lots of $FreeBSD$ changes. In a lot of the files that is the only
change.
The additions in lib/Makefile, share/man/man5/Makefile should be sorted
alphabetically.
I think libbluetooth and libsdp should be added to share/mk/bsd.libnames.mk
and then the Makefiles should be modified to use ${LIBBLUETOOTH} and ${LIBSDP}
on the DPADD lines. /usr/lib/libbluetooth.a should not be hardcoded otherwise
buildworld won't work correctly.
The + after DPADD and LDADD should be removed. It should only be used when
a Makefile have more than one DPADD or LDADD line
There should not be '-L/usr/lib' on the LDADD line.
PS. Will Julian commit it when there was a review or are you looking
for a committer too?
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth patch
I have prepared Bluetooth mega patch for FreeBSD source tree. This patch
updates FreeBSD sources to the most recent snapshot.
[...]
The patch could be downloaded from
http://www.geocities.com/m_evmenkin/patch/bluetooth20030914.diff.gz
I had a look at the patch and here is my comments. I haven't tried it
yet, but I did try your latest snapshot.
good, did it (snapshot) work for you?
Yes, I got a bluetooth ppp session going between 2 FreeBSD boxes with
usb-bluetooth devices.
I haven't looked at the man
page markup, someone more knowledgable can do that, or it can be
committed and then Ruslan can have a look at it when he gets time.
i tried to follow original man page style. it is possible that i missed
few minor things, but in general i think it should be fine. my plan was
to double check everything after commit and deal with the issues.
That is ok.
There are lots of $FreeBSD$ changes. In a lot of the files that is the only
change.
i see, is that a problem? i can clean up the patch and remove these entries.
(frankly i thought CVS should take care of it).
I don't think it will break cvs, it might just cause some extra bloat.
Maybe just get rid of those parts of the patch where the only change
to the file is the $FreeBSD$ line?
The additions in lib/Makefile, share/man/man5/Makefile should be sorted
alphabetically.
sure, i assume i should sort entries in lib/Makefile for
.if ${MACHINE_ARCH} == i386 section right?
Yes, that too, but inside such a block it should be alphabetical. SUBDIR
should also be alphabetical except for those mentioned in the comments at
the top of src/lib/Makefile.
I think libbluetooth and libsdp should be added to share/mk/bsd.libnames.mk
and then the Makefiles should be modified to use ${LIBBLUETOOTH} and
${LIBSDP}
on the DPADD lines. /usr/lib/libbluetooth.a should not be hardcoded
otherwise
buildworld won't work correctly.
ok, i missed that one :) thanks!
The + after DPADD and LDADD should be removed. It should only be used when
a Makefile have more than one DPADD or LDADD line
There should not be '-L/usr/lib' on the LDADD line.
got it.
so, i hope those are minor things. can they be resolved right after commit
is done? or i must fix them and submit revised patch?
I would prefer a patch with the makefile stuff fixed so that I can push
it through a make world and a make release before committing.
PS. Will Julian commit it when there was a review or are you looking
for a committer too?
Julian and Ruslan are busy at the moment. M. Warner Losh has sent e-mail
to core@ and asked for commit bit for me. in the mean time i'd like to
commit this and resolve all issues in time for 5.2-RELEASE.
I can give it a go if no one else wants to do it.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth patch
On Mon, Sep 29, 2003 at 05:49:08PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Hay [EMAIL PROTECTED] writes: : Julian and Ruslan are busy at the moment. M. Warner Losh has sent e-mail : to core@ and asked for commit bit for me. in the mean time i'd like to : commit this and resolve all issues in time for 5.2-RELEASE. : : I can give it a go if no one else wants to do it. The core approval process for committers takes one week, so he should have his commit bit in plenty of time. Hey, I didn't realise the process was that far already. My initial reaction was because it looked like nobody else reacted and I got tired of having to add the bluetooth snap everytime. :-) However, if you'd like to help review the changes before/as they go into the tree, my feelings won't be hurt :-) If you need help time wise I'd be happy to help. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
On Tue, Sep 16, 2003 at 11:16:54AM -0700, Julian Elischer wrote: I'm not sure what I typed there but what I meant to say was At one stage the wi driver could not be put in promiscuous mode and the bridging code required that. Most people still think this is true. I think it is still true. What you can do is bridging between ethernet and wireless if you use host-ap mode. What you can't do is bridging ethernet-wireless --- wireless-ethernet. For that you will need WDS or something similar. On Tue, 16 Sep 2003, Sam Leffler wrote: I think what he meant was that at on state was known (I don't know the current state) that as the wi could not be but in promiscuous mode it could not be used for bridging.. Bridging requires promiscuous mode (or some very tricky proxy-arp stuff). You can put wi (and ath) in promiscuous mode. The bridge manual page is wrong and I will fix it. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BOOTMFS requires 'device miibus'
Please try the attached patch instead, and let me know if it fixes
the release build. You can try ``make rerelease'' to speed up the
things, after applying this patch in ${CHROOTDIR}/usr/src.
Index: release/i386/drivers.conf
===
...
+bfe if_bfe 3 network Broadcom BCM440x 10/100 ethernet
...
+re if_re 3 network RealTek 8139C+/8169/8169S/8110S
...
Those 2 don't fit on the drivers floppy. Without them, the floppy
stats from the release output looks like this:
+ df -ki /mnt
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/md0c 1391 13741799% 57 5 92% /mnt
+ df+ tail -ki -1 /mnt
+ set /dev/md0c 1391 1374 17 99% 57 5 92% /mnt
+ echo *** Filesystem is 1440 K, 17 left
*** Filesystem is 1440 K, 17 left
+ echo *** 4 bytes/inode, 5 left
*** 4 bytes/inode, 5 left
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster b0rked?
for i in answer isdntel.sh record tell tell-record unknown_incoming ; do install -o -g -m 700 $i /var/tmp/temproot/etc/isdn ; done ; for i in holidays.Disdnd.rates.Aisdnd.rates.D isdnd.rates.F isdnd.rates.L isdnd.rates.UK.BT isdnd.rc.sample isdntel.alias.sample ; do install -o -g -m 600 $i /var/tmp/temproot/etc/isdn ; done install: -g: Invalid argument *** Error code 67 Stop in /usr/src/etc/isdn. *** Error code 1 Stop in /usr/src/etc. *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the temproot environment # I'm seeing this too. I've cvsup'ed and rebuilt world (making sure that mergemaster was rebuilt) and it still occurs. Make sure to get a more clever src/etc/isdn/Makefile. I think 1.11 should do. PS. It broke my nightly release build too. I'm now trying again with the latest Makefile. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
On Tue, Jul 29, 2003 at 11:28:18PM -0700, Nate Lawson wrote: On Wed, 30 Jul 2003, John Hay wrote: Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) There's nothing sinister going on here. What happens is your device is slow to power up and initialize when plugged in. It's not ready for the bus scan from CAM but it's awake enough to answer the initial INQUIRY. When you boot with it attached, there's a longer delay between when the port is powered up and CAM scans the device and so you don't get any messages. What behavior does the device give after you get the above dmesg? Does it print out errors on console that the retry failed? (see last line of the dmesg). I've been thinking about adding a bit of a delay to the umass CAM attach call for such devices. The last message is Opened disk da0 - 6. That is a little strange because I thought we only do 10 byte commands to usb devices. The problem is that only da0 pitch up in the /dev directory. There should be a da0s1 too. Using fdisk on da0 does show what looks like a valid partition table with one DOS partition. I have tried camcontrol reset, inquiry, start and rescan, but can't get da0s1 to make its appearance. uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xece0-0xecff irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 Port powered up. [~3 secs, perhaps] ad0: 6194MB IBM-DADA-26480 [13424/15/63] at ata0-master UDMA33 acd0: CDROM TEAC CD-ROM CD-224E at ata1-master PIO4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 14MB (29120 512 byte sectors: 64H 32S/T 14C) Device probed. Yip, if I get that far, the disk is accessable. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) ... What behavior does the device give after you get the above dmesg? Does it print out errors on console that the retry failed? (see last line of the dmesg). I've been thinking about adding a bit of a delay to the umass CAM attach call for such devices. The last message is Opened disk da0 - 6. No, according to your message it's Retrying Command (per Sense Data). Yip, you are right, I was looking here locally, but that was after trying lots of camcontrol commands. That is a little strange because I thought we only do 10 byte commands to usb devices. That message is from GEOM and has nothing to do with 10 byte commands. ok The problem is that only da0 pitch up in the /dev directory. There should be a da0s1 too. Using fdisk on da0 does show what looks like a valid partition table with one DOS partition. I have tried camcontrol reset, inquiry, start and rescan, but can't get da0s1 to make its appearance. Sounds like a GEOM problem. Unless you have other errors from da0 after the last line you posted, it appears the command retry attempt succeeded. At that point, the problem is likely with GEOM not parsing the partition table when it appears and making the slice show up. But I don't know enough about GEOM to claim this its fault. Ok, but why does geom pick it up correctly when booting with the disk plugged in? Does geom mabe get called before the disk is ready? If that Opened disk ... message is from geom, the order of things looks like geom gets called just after the Unretryable error. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
strange umass/scsi behaviour
: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port 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: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec cardbus0: Resource not specified in CIS: id=14, size=80 cardbus0: Resource not specified in CIS: id=18, size=80 xl0: 3Com 3c575C Fast Etherlink XL port 0x1000-0x107f mem 0x88002000-0x8800207f,0x88002080-0x880020ff irq 11 at device 0.0 on cardbus0 xl0: Ethernet address: 00:50:da:b0:ab:e5 miibus0: MII bus on xl0 tdkphy0: TDK 78Q2120 media interface on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ad0: 6194MB IBM-DADA-26480 [13424/15/63] at ata0-master UDMA33 acd0: CDROM TEAC CD-ROM CD-224E at ata1-master PIO4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 14MB (29120 512 byte sectors: 64H 32S/T 14C) Mounting root from ufs:/dev/ad0s2a # Here I pull it out. umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached # And plug it back in. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pnp code and irq 2 problem
Hi, Somewhere along the line the code in FreeBSD that maps irq 2 to irq 9 has gone away and a panic was added if one tries to use irq 2. This is all well and fine, except that the pnp code was not notified of this. :-) So if you have a pnp device that have irq 2 in its mask and FreeBSD then decides that irq 2 is a good irq to use for this device, you have an instant panic. I have worked around it with this crude patch below. Crude because: 1) I don't know if it should be an i386 only fix, and 2) I used 0x04 directly, maybe IRQ_SLAVE from i386/isa/icu.h or some other difine should be used? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Index: isa/pnpparse.c === RCS file: /home/ncvs/src/sys/isa/pnpparse.c,v retrieving revision 1.13 diff -u -r1.13 pnpparse.c --- isa/pnpparse.c 16 Oct 2002 09:07:30 - 1.13 +++ isa/pnpparse.c 19 Jun 2003 06:00:02 - @@ -110,7 +110,8 @@ if (bootverbose) pnp_printf(id, adding irq mask %#02x\n, I16(res)); - config-ic_irqmask[config-ic_nirq] = I16(res); + config-ic_irqmask[config-ic_nirq] = I16(res) + ~0x04; config-ic_nirq++; break; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: should fdisk -BI still work?
On Tue, Jul 01, 2003 at 08:20:11AM -0700, Brooks Davis wrote: On Tue, Jul 01, 2003 at 11:15:49AM +0200, John Hay wrote: Hi, Should fdisk -BI ad0 still work on current? I have a script that I use to prepare flash disks that have worked for a long time on older versions of FreeBSD, but it seems a little broken on -current. It actually started with the one from Warner's site people.../~imp/diskprep.pl and tweaked it over time to keep it running. On current I get an error when doing fdisk -BI ad0: fdisk: invalid fdisk partition table found So how is one supposed to create a FreeBSD slice nowadays from a script? I'm not using -BI, but I am using -I in a version of diskprep. Are you sure you don't have any slices (or partitions inside those slices) open? I remember getting all sorts of weird errors when I forgot about that while developing my new scripts. Sorry guys, false alarm. There was something wrong with that flash disk. It probed ok, but ignored writes to the first sector. :-/ I tried with a different one and it is working now. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
should fdisk -BI still work?
Hi, Should fdisk -BI ad0 still work on current? I have a script that I use to prepare flash disks that have worked for a long time on older versions of FreeBSD, but it seems a little broken on -current. It actually started with the one from Warner's site people.../~imp/diskprep.pl and tweaked it over time to keep it running. On current I get an error when doing fdisk -BI ad0: fdisk: invalid fdisk partition table found So how is one supposed to create a FreeBSD slice nowadays from a script? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: kmem_malloc(4096): kmem_map too small
Hi, On a 5.1-RELEASE machine I have been able to cause a panic like this: panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated The machine is an old 300MHz Celeron with 64M Ram. I get the panic by un-taring a huge .tgz file onto a vinum partition which is on a scsi disk behind a Adaptec 2940 controller. The huge tar file contains a normal user 5.1 installation plus the 5.1-RELEASE bits from the ftp site, so it is a 320 Meg .tgz. I have played around a bit. It seems to panic a little quicker if the machine have only 32M Ram. I haven't been able to panic it if I do it in a normal, non-vinum partition. I don't know if vinum is at fault though, it might just help to agravate the situation. Here follow the output of vinum list and then the panic message and a gdb traceback. I'm not sure if the traceback is correct. I think it only show the second panic. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] The output of vinum list: ### 1 drives: D vd0 State: up /dev/da0s1d A: 0/966 MB (0%) 1 volumes: V root State: up Plexes: 1 Size:966 MB 1 plexes: P root.p0 C State: up Subdisks: 1 Size:966 MB 1 subdisks: S root.p0.s0State: up D: vd0 Size:966 MB ### GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd... panic: free locked buf panic messages: --- panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated syncing disks, buffers remaining... panic: free locked buf Uptime: 1h47m5s (da0:ahc0:0:6:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da0:ahc0:0:6:0): error code 54 Dumping 64 MB ata0: resetting devices .. done 16 32 48 --- Reading symbols from /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug #0 doadump () at ../../../kern/kern_shutdown.c:238 238 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:238 #1 0xc01ab1ca in boot (howto=260) at ../../../kern/kern_shutdown.c:370 #2 0xc01ab483 in panic () at ../../../kern/kern_shutdown.c:543 #3 0xc1064926 in freerq (rq=0xc166c4c0) at /usr/src/sys/dev/vinum/vinuminterrupt.c:252 #4 0xc106482a in complete_rqe (bp=0xc12a6c24) at /usr/src/sys/dev/vinum/vinuminterrupt.c:230 #5 0xc01eda81 in bufdone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:3086 #6 0xc01ed984 in bufdonebio (bp=0x0) at ../../../kern/vfs_bio.c:3034 #7 0xc01ed7e2 in biodone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:2961 #8 0xc017d4be in g_dev_done (bp2=0xc1552120) at ../../../geom/geom_dev.c:391 #9 0xc01ed7e2 in biodone (bp=0xc1552120) at ../../../kern/vfs_bio.c:2961 #10 0xc017fc62 in g_io_schedule_up (tp=0xc0607e40) at ../../../geom/geom_io.c:365 #11 0xc017fe58 in g_up_procbody () at ../../../geom/geom_kern.c:91 #12 0xc01986ce in fork_exit (callout=0xc017fe30 g_up_procbody, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:768 (kgdb) quit ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AC97 sound problems with current
| There is a calibration step in the driver to determine the clock rate of th | e | AC97 link. What you are seeing is the calibration step failing and setting | a | bogus ac97 link rate. I took a cursory look a couple of weeks back and it | smelt like the timecounter initialization point changed, but haven't gotten | | around to looking closer and fixing the driver. It's definitely nothing to do with the timecounter - quick test on other h/w along similar lines. I don't access to an ich board to test on - it's probably obvious, but I'm not seeing it just now with visual inspection... It doesn't look like it is the timecounters. I just added some printfs and it looks like this: pcm0: measured ac97 link rate at 51200 Hz t1 1.098359, t2 1.098363 ociv 0, nciv 1, bytes 8192 tsc1 445813142, tsc2 445821922, diff 8780 The tsc values are just from rdtsc(), I added tsc1 = rdtsc() just above the first microtime() and tsc2 just after the last. My machine is a 1.8G P4 (ICH2), so the timecounter values seem correct. I have kernel around the middle of Feb that gets the value right and one from March 4 that gets it all wrong. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.0-CURRENT diskless boot recognition
As I posted prior to this question, I have problems in getting diskless started with 5.0-Current as cvsupdated today. The problem is still the same and after a night of hairloosing work I think I got closer to the problem. We use PXE as bootstrap environment, isc-dhcp and a read-only disk partition /usr/diskless conatining for each architecture we boot diskless its appropriate directory. The diskless kernels are compiled with individual 'ident Marker', have options NFS_ROOT, MD_ROOT, UNIONFS, PSEUDOFS and device md. The whole setup is as described in /etc/rc.d/initdiskless with special /conf-dir entries and this scheme works perfect under FreeBSD 4.7. I don't think you need MD_ROOT or UNIONFS. I also have BOOTP, BOOTP_NFSROOT and BOOTP_NFSV3. FreeBSD 5.0-CURRENT seems to have problems within its bootstrap process to recognize that it is a diskless system. After the diskless station got its IP, loaded and booted the kernel I see this on screen: Mounting root from nfs: NF ROOT: MY.IP : /usr/diskless/xterm Loading configuration files. Starting file system checks: mount: / : unknown special file or filesystem Do you have a mount point for / in fstab? I have something like this: my.nfs.ip.number:/export/current / nfs ro 0 0 Mounting NFS file system:. eval: /etc/rc.d/cleanvar: Permission denied. . . . After the last message a lot of deny error occur. I modified all the diskless-scripts in rc.d with my own echo commands to check which one gets involved, but none of them get touched! The above process looks identical of what a normal standalone machine does when booting. No wonder when diskless does not work when the init process does not recognize that it is booting diskless. The only mods that I made was to mount /var over NFS and not as a RAM disk. It would be nice if there was a knob to select that. :-) We do not use BOOTP and I do not know whether FBSD 5.X does only support this scheme. We would like to stay with the NFS process. But I think technically this can not be the problem, because after the station has already booted the kernel it doesnt care what mechanism it booted from. NFS is the dominating facility and I could see, the root partition got mounted as expected. Remember BOOTP is just a subset of DHCP. Actually the BOOTP in the kernel will first try dhcp requests before fallng back, IIRC. And it seems to need it in -current while it didn't when I last did a -stable diskless setup. Can anyone help? Do I mark each kernel with 'ident DISKLESS' to give the init process any idea what it should do? I use DLESS, so it shouldn't be necesary. :-) Well I learned a lot by watching tcpdump while it is all happening. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Re: cc: Internal error: Illegal instruction (program as)
I thought this was the default in 5.x GENERIC; has someone turned these options off in the default config?!? I certainly haven't seen changes to locore.s, pmap.c, and machdep.c that would fix the problem by working around the CPU bug. Can't say anything for Paul's case, he probably had custom kernel then? If I can remember peter did the options conditional for CPU type, so only P4 owners get'em at boot time. Check the Feb 12 commit logs. He did add code to do it, but disabled it again in the next commit. See rev 1.386 and 1.387 of sys/i386/i386/pmap.c. Note the _nots at the end of the #ifdefs. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
On Sat, Feb 22, 2003 at 11:43:01AM -0500, Paul A. Howes wrote: All, I am receiving some strange errors during a buildworld of 5.0-RELEASE-p2 from 5.0-RELEASE-p1. The location of where the failure varies, but the program that causes the failure is the same every time: as. The errors are a variety of signal 10 and signal 4. I do find an as.core file under /usr/obj, but as is stripped, so there are no debugging symbols or listing that I can provide. The strange thing is that I have been able to successfully build XFree86, KDE, and many other ports on this system. I followed the 4.x-to-5.0 upgrade directions to the letter about a month ago, and have had no major problems before this. Any help would be greatly appreciated! -- Paul A. Howes Hardware Tyan S2099GNNR motherboard Intel P4-2.4/533 Crucial 512 MB PC2100 DIMM Maxtor 20 GB hard drive. I see it is a P4, try adding options DISABLE_PSE and DISABLE_PG_G to your kernel. My 1.8G P4 do the same without them. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
usb patch: outgoing interrupt pipes
Hi,
I have a patch that adds outgoing interrupt pipes to the usb stack. I
needed it to make a Lego infrared tower work with FreeBSD. Outgoing
interrupt pipes are part of the USB 1.1 spec, but I think our usb
code comes from before that, so it only have incoming interrupt pipes.
Is there anybody that would like to review this or shall I just go
ahead and commit it? One thing to note is that the patch only fix
it for uhci controllers. I haven't been able to get my hands on an
ohci controller.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
Index: share/man/man4/ugen.4
===
RCS file: /home/ncvs/src/share/man/man4/ugen.4,v
retrieving revision 1.2
diff -u -r1.2 ugen.4
--- share/man/man4/ugen.4 22 Nov 2001 11:56:54 - 1.2
+++ share/man/man4/ugen.4 14 Feb 2003 10:20:01 -
-104,9 +104,12
should be used.
All I/O operations on a bulk endpoint are unbuffered.
.Pp
-The interrupt transfer mode can only be in.
-To perform input from an interrupt endpoint
+The interrupt transfer mode can be in or out depending on the
+endpoint.
+To perform I/O on an interrupt endpoint
.Xr read 2
+and
+.Xr write 2
should be used.
A moderate amount of buffering is done
by the driver.
Index: sys/dev/usb/ugen.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.66
diff -u -r1.66 ugen.c
--- sys/dev/usb/ugen.c 21 Jan 2003 08:55:44 - 1.66
+++ sys/dev/usb/ugen.c 12 Feb 2003 16:05:24 -
-419,6 +419,13
edesc = sce-edesc;
switch (edesc-bmAttributes UE_XFERTYPE) {
case UE_INTERRUPT:
+ if (dir == OUT) {
+ err = usbd_open_pipe(sce-iface,
+ edesc-bEndpointAddress, 0, sce-pipeh);
+ if (err)
+ return (EIO);
+ break;
+ }
isize = UGETW(edesc-wMaxPacketSize);
if (isize == 0) /* shouldn't happen */
return (EINVAL);
-764,6 +771,30
DPRINTFN(1, (ugenwrite: transfer %d bytes\n, n));
err = usbd_bulk_transfer(xfer, sce-pipeh, 0,
sce-timeout, buf, n,ugenwb);
+ if (err) {
+ if (err == USBD_INTERRUPTED)
+ error = EINTR;
+ else if (err == USBD_TIMEOUT)
+ error = ETIMEDOUT;
+ else
+ error = EIO;
+ break;
+ }
+ }
+ usbd_free_xfer(xfer);
+ break;
+ case UE_INTERRUPT:
+ xfer = usbd_alloc_xfer(sc-sc_udev);
+ if (xfer == 0)
+ return (EIO);
+ while ((n = min(UGETW(sce-edesc-wMaxPacketSize),
+ uio-uio_resid)) != 0) {
+ error = uiomove(buf, n, uio);
+ if (error)
+ break;
+ DPRINTFN(1, (ugenwrite: transfer %d bytes\n, n));
+ err = usbd_intr_transfer(xfer, sce-pipeh, 0,
+ sce-timeout, buf, n,ugenwi);
if (err) {
if (err == USBD_INTERRUPTED)
error = EINTR;
Index: sys/dev/usb/uhci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/uhci.c,v
retrieving revision 1.130
diff -u -r1.130 uhci.c
--- sys/dev/usb/uhci.c 21 Jan 2003 08:55:44 - 1.130
+++ sys/dev/usb/uhci.c 12 Feb 2003 16:27:48 -
-149,6 +149,7
/* Interrupt pipe */
struct {
int npoll;
+ int isread;
uhci_soft_qh_t **qhs;
} intr;
/* Bulk pipe */
-2032,6 +2033,7
uhci_soft_td_t *data, *dataend;
uhci_soft_qh_t *sqh;
usbd_status err;
+ int isread, endpt;
int i, s;
if (sc-sc_dying)
-2045,8 +2047,15
panic(uhci_device_intr_transfer: a request\n);
#endif
- err = uhci_alloc_std_chain(upipe, sc, xfer-length, 1, xfer-flags,
- xfer-dmabuf, data, dataend);
+ endpt = upipe-pipe.endpoint-edesc-bEndpointAddress;
+ isread = UE_GET_DIR(endpt) == UE_DIR_IN;
+ sqh = upipe-u.bulk.sqh;
+
+ upipe-u.intr.isread = isread;
+
+ err = uhci_alloc_std_chain(upipe, sc, xfer-length, isread,
+ xfer-flags, xfer-dmabuf, data
Re: FreeBSD/i386 kern.flp flooding again
fstab: /etc/fstab:0: No such file or directory /dev/md1c: 1.4MB (2880 sectors) block size 4096, fragment size 512 using 1 cylinder groups of 1.41MB, 360 blks, 32 inodes. super-block backups (for fsck -b #) at: 32 + mount /dev/md1c /mnt + [ -d /R/stage/image.kern ] + set -e + cd /R/stage/image.kern + find+ cpio -dump . -print /mnt cpio: write error: No space left on device *** Error code 1 (End quote) What about moving the slip driver (sl) to the drivers floppy? I know its not much, but it is enough to make things fit on the floppy again. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dsp device busy (me too) vchans weirdness
On Wed, Feb 12, 2003 at 08:46:09AM -0600, Craig Boston wrote: I remember a couple of posts about this problem; but don't recall (and am unable to find in the archives) if there was ever any resolution. I have experienced the same thing. I have tried vchan sound on three -current boxes and it works on all but the Dell. The Dell also have the ICH2 sound while the other two have different sound chips. Maybe it has something to do with the ICH driver or else I was just lucky with the other machines. On the Dell have tried setting vchans directly and maxautovchans, but neither did work for me. I did see this on the console though: ## lock order reversal 1st 0xc87d5b00 pcm0:virtual:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd 0xc5d99a80 pcm0 (sound cdev) @ /usr/src/sys/dev/sound/pcm/sound.c:163 ## Just switching vchans off on the Dell made the sound work again. Anyway, this just started on a RELENG_5_0 box this morning -- been working fine up until now. I noticed that /dev/dsp wasn't being cloned, so I went about trying individual devices... $ esd -d /dev/dsp0.1 - using device /dev/dsp0.1 /dev/dsp0.1: Device busy $ esd -d /dev/dsp0.2 - using device /dev/dsp0.2 /dev/dsp0.2: Device busy $ fstat /dev/dsp0.0 $ fstat /dev/dsp0.1 $ fstat /dev/dsp0.2 $ cat /dev/dsp0.3 cat: /dev/dsp0.3: Device busy etc... I've double checked and there is NOTHING running that's touching any of the sound devices (which the fstat confirms). Oddly enough, when I was randomly 'cat'-ing sound devices, one of them returned Operation not supported by device. It only did this once, and then went back to Device busy every time after that. $ dmesg | grep pcm pcm0: Intel 82801BA (ICH2) port 0xcc40-0xcc7f,0xc800-0xc8ff irq 10 at device 31.5 on pci0 pcm0: measured ac97 link rate at 55934 Hz $ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: Intel 82801BA (ICH2) at io 0xc800, 0xcc40 irq 10 bufsz 16384 (1p/1r/4v channels duplex default) $ sysctl hw.snd hw.snd.targetirqrate: 32 hw.snd.report_soft_formats: 1 hw.snd.verbose: 1 hw.snd.unit: 0 hw.snd.maxautovchans: 0 hw.snd.pcm0.buffersize: 16384 hw.snd.pcm0.vchans: 4 hw.snd.pcm0.ac97rate: 55934 I'm not using maxautovchans because that seems to cause random reboots on this hardware (happens with two Dell towers, both with the ICH2 chip). Even weirder still, during the course of writing this mail, dsp0.[1-4] have spontaneously started working again. 0.0 still reports device busy, though that may be normal since the vchans are active. I was going to try changing the number of vchans to see if it had any effect, but since it's working for now I'll try that next time it happens. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dsp device busy (me too) vchans weirdness
On Wed, Feb 12, 2003 at 08:31:11PM +0200, John Hay wrote: On Wed, Feb 12, 2003 at 08:46:09AM -0600, Craig Boston wrote: I remember a couple of posts about this problem; but don't recall (and am unable to find in the archives) if there was ever any resolution. I have experienced the same thing. I have tried vchan sound on three -current boxes and it works on all but the Dell. The Dell also have the ICH2 sound while the other two have different sound chips. Maybe it has something to do with the ICH driver or else I was just lucky with the other machines. On the Dell have tried setting vchans directly and maxautovchans, but neither did work for me. I did see this on the console though: ## lock order reversal 1st 0xc87d5b00 pcm0:virtual:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd 0xc5d99a80 pcm0 (sound cdev) @ /usr/src/sys/dev/sound/pcm/sound.c:163 ## Just switching vchans off on the Dell made the sound work again. Looks like I have to take that back. I just tried a brand new -CURRENT kernel and vchans are now working. I have only tried it by setting hw.snd.maxautovchans. It does produce a lot of could sleep with messages though: ## ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:163 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:163 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:163 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:434 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:434 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:434 ### John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new wi driver
Hi Sam, The new device wlan option is pushing the kern.flp over the limit during make release. Maybe it can be moved to mfsroot.flp? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
USB is only the transport. It doesn't add or remove functionality (the only exception being probing for LUNs on CBI devices). If you want to determine the geometry you will have to do this through SCSI commands. I was hoping that the CAM code would be smart enough to request the details from the drive itself, but perhaps there is a good reason for asking the controller for this. It did work without, so it hasn't been implemented yet. Feel free to suggest a SCSI command together with the logic. What is the GET_GEOMETRY used for anyway? Well the short version of the problem is that fdisk -BI disk works on -stable to get a FreeBSD partition on the Compact Flash. This does not work on -current anymore. I have traced that back to the commit in umass.c rev 1.61 that removed the fake geometry setting and just leave the cylinders, heads and sectors_per_track zero. This cause fdisk to coredump with a floating point error. In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : We should obviously fix it. I have no idea what is possible in USB : devices in this respect. Nor do I. Maybe there's some SCSI command that we can send that is well defined enough to work often enough. However, I'm not clueful enough about SCSI to know if this can be done (likely reading some mode page will do it in real SCSI), nor about USB's mass storage devices, nor about all the wonderful and weird variations that one might find in the wild... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
Well the short version of the problem is that fdisk -BI disk works on -stable to get a FreeBSD partition on the Compact Flash. This does not work on -current anymore. I have traced that back to the commit in umass.c rev 1.61 that removed the fake geometry setting and just leave the cylinders, heads and sectors_per_track zero. This cause fdisk to coredump with a floating point error. Hm, strange. I would think that a compact flasg is an ATAPI over CBI device (see attach message in your dmesg). If that is the case, the 'fake setting' was not done in STABLE either and I would expect the problem to be somewhere else. But that would contradict your research. Maybe the short version was too short. :-) The CF is behind a SanDisk ImageMate (I have two different ones), which emulates SCSI according to dmesg. I don't know if they use BBB or CBI. I don't know what the difference is either. :-) umass0: SanDisk ImageMate CF-SD, rev 1.10/0.12, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk ImageMate CF-SD1 0100 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 61MB (125440 512 byte sectors: 0H 0S/T 0C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2 umass0: Get Max Lun not supported (STALLED) da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 61MB (125441 512 byte sectors: 0H 0S/T 0C) # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
Let's work on the 'proper' solution first.
What SCSI commands are suitable for getting the geometry, generically
on a device?
Hmmm, I made an interesting discovery. I searched through some of the
scsi drivers, sys/dev/{aha|ahb|aic*|sym}, looking for XPT_CALC_GEOMETRY
and they all fake the geometry. :-/
fdisk likely should do something sane in the face of such insanity,
but it is unclear what and fdisk is a royal pita to work on anyway :-(
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
: Hmmm. I just noticed that the disks probe with zero values for the
: heads, sectors/track and cylinders. I have tried two different USB
: CF readers and both do it. On 4.x it probes with the correct values
: on the same machine and the same devices. So why do they probe
: wrong?
Don't know. I've had problems with CF readers returning the wrong
geometry values in 4.3, but never 0's
Ok, I found it. It is part of the rev 1.61 change to umass.c. It was
made in June. :-/ The relevant piece is this:
###
Index: umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- umass.c 11 Apr 2002 21:09:41 - 1.60
+++ umass.c 16 Jun 2002 20:53:35 - 1.61
...
@@ -2445,35 +2441,16 @@
}
case XPT_CALC_GEOMETRY:
{
+#ifdef UMASS_DEBUG
struct ccb_calc_geometry *ccg = ccb-ccg;
-
+#endif
DPRINTF(UDMASS_SCSI, (%s:%d:%d:%d:XPT_CALC_GEOMETRY:
- Volume size = %d\n,
+ Volume size = %d (unimplemented)\n,
USBDEVNAME(sc-sc_dev), cam_sim_path(umass_sim),
ccb-ccb_h.target_id, ccb-ccb_h.target_lun,
ccg-volume_size));
- /* XXX We should probably ask the drive for the details
-* instead of cluching them up ourselves
-*/
- if (sc-drive == ZIP_100) {
- ccg-heads = 64;
- ccg-secs_per_track = 32;
- ccg-cylinders = ccg-volume_size / ccg-heads
- / ccg-secs_per_track;
- ccb-ccb_h.status = CAM_REQ_CMP;
- break;
- } else if (sc-proto PROTO_UFI) {
- ccg-heads = 2;
- if (ccg-volume_size == 2880)
- ccg-secs_per_track = 18;
- else
- ccg-secs_per_track = 9;
- ccg-cylinders = 80;
- break;
- } else {
- ccb-ccb_h.status = CAM_REQ_CMP_ERR;
- }
+ ccb-ccb_h.status = CAM_REQ_CMP_ERR;
xpt_done(ccb);
break;
..
###
If I understand this correctly, it means it just faked the geometry, which
explains Warner's comment that it didn't get the geometry always right.
So the question now is do we just leave umass like this, which means we
can't do low level disk stuff on umass devices, or do we add something
like this back or is there another way? Is there a way to get the real
geometry of the device?
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
fdisk -BI ob clean disk broken
On 4.x I have been using a slightly modified version of Warner's diskprep
to write new compact flashes. On -current fdisk die with signal 8 (Floating
point exception) when this part of the script runs:
$dev = /dev/r${drive};
system /bin/dd if=/dev/zero of=$dev count=128 /dev/null 21;
system /sbin/fdisk -BI $drive;
$dev is normally da0, which is the compact flash plugged into a Sandisk
usb CF reader.
So is there a better way in the GEOM world to achieve the same thing?
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: What is user uucp good for?
Now that uucp is no longer in the base system, is there any reason to keep user uucp in /usr/src/etc/master.passwd? Probably not. If you remove this, please coordinate an upgrade to the net/freebsd-uucp port the get the user added there. Also remember that /dev/cua* is owned by uucp. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fdisk -BI ob clean disk broken
: On 4.x I have been using a slightly modified version of Warner's diskprep
: to write new compact flashes. On -current fdisk die with signal 8 (Floating
: point exception) when this part of the script runs:
:
: $dev = /dev/r${drive};
: system /bin/dd if=/dev/zero of=$dev count=128 /dev/null 21;
: system /sbin/fdisk -BI $drive;
:
: $dev is normally da0, which is the compact flash plugged into a Sandisk
: usb CF reader.
The reason that I do a dd first is to obliterate any MBR that's
there. The intent is to force fdisk to fetch the actual disk geometry
from the disk so that the fdisk lable that is placed on there will
work as a boot disk. Before I added the dd in 4.x, I found that many
CF came with MBRs that didn't match their actual geometry, so when I
tried to boot them, things failed.
Does removing the dd eliminate the problem? If so, that's likely a
bug in GEOMification of fdisk.
Hmmm. I just noticed that the disks probe with zero values for the
heads, sectors/track and cylinders. I have tried two different USB
CF readers and both do it. On 4.x it probes with the correct values
on the same machine and the same devices. So why do they probe
wrong?
#
umass0: SanDisk ImageMate CF-SD, rev 1.10/0.12, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SanDisk ImageMate CF-SD1 0100 Removable Direct Access SCSI-0 device
da0: 1.000MB/s transfers
da0: 61MB (125440 512 byte sectors: 0H 0S/T 0C)
umass0: at uhub0 port 1 (addr 2) disconnected
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
umass0: detached
umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2
umass0: Get Max Lun not supported (STALLED)
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: 61MB (125441 512 byte sectors: 0H 0S/T 0C)
###
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: The next make release breaker...
Jun Kuriyama [EMAIL PROTECTED] writes: At Wed, 30 Oct 2002 13:01:32 +0100, Dag-Erling Smorgrav wrote: The *installed* libssh shouldn't matter. What matters is the libssh which is built during 'make world' inside the chroot. That's what sshd should be linked against. Sorry for my misunderstanding. You mention $chrootdir/usr/obj/usr/src/secure/lib/libssh/libssh.a, right? Yes, that's what I mean. % cd $chrootdir/usr/obj/usr/src/secure/lib/libssh % nm libssh.a | grep mm_auth 05e0 T mm_auth2_read_banner 06f0 T mm_auth_password 0820 T mm_auth_rhosts_rsa_key_allowed 1df0 T mm_auth_rsa_generate_challenge 1d00 T mm_auth_rsa_key_allowed 1ef0 T mm_auth_rsa_verify_response That's definitely not right :( The part where it is failing is in release.3 of release/Makefile. Following that around libssh should probably be rebuilt with K5, so shouldn't KPROGS in kerberos5/Makefile also have secure/lib/libssh? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))
Can you try the patch at: http://people.freebsd.org/~deischen/sys.diffs It works! Already 5 hours without a single signal 6. Thanks! Let me test it myself and I'll commit it as a (yet another) work around until mini gets a chance to make new syscalls to handle this better. Another me too. With the patch I was finally able to finish a cvsup session. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))
In article [EMAIL PROTECTED], Andrey A. Chernov [EMAIL PROTECTED] wrote: The bug completely gone after I revert machdep.c to 1.538. This commit cause bug: revision 1.539 date: 2002/09/30 07:02:22; author: obrien; state: Exp; lines: +10 -0 Save the FP state in the PCB as that is compatable with releng4 binaries. This is a band-aid until the KSE pthread committers get back on the ground and have their machines setup. Submitted by: eischen Good sleuthing! Additional details: it cause not only cvsupd death, but rarely cvsup signal 6 death too with this diagnostic: *** *** runtime error: ***Value out of range ***file /tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/Time Stamp.m3, line 63 This particular message is usually caused by a very bogus system date setting. I also see this on current using cvsup and my machine is synced with ntpd, so its time is ok. I have tried a few different versions of cvsup, but they all do the same thing. I have not tried to compile my own yet. In my case cvsup die everytime I try to use it. It go through the src but breaks somewhere in ports/math. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: netns
Why don't they use the netipx code? Surely netware use ipx. I believe there are people whi use it in -stabel for netware connectivity. I think that not having it would be a killer for them when they try move up to 5.x. On Sun, 22 Sep 2002, Erik Greenwald wrote: Does anyone use src/sys/netns (xerox networking)? it's currently uncompilable, seems to have been so for a while, and sys/conf/NOTES says it's provided for amusement value, and are only shipped due to interest. I wouldn't mind seeing it go away in -current and if someone wants it, they can cvs an older version or something... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: netns
John Hay wrote: Why don't they use the netipx code? Surely netware use ipx. IPX is based on XNS. It differs by one significant field. The SAP (Service Advertisement Protocol) in IPX comed directly from XNS. So you are agreeing with me that to use netns to do ipx when we have netipx does not make sense? :-) FWIW. I know, a lot of my time went into netipx, which was derived from netns. I also did IPXrouted which does SAP too. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: netns
Why don't they use the netipx code? Surely netware use ipx. IPX is based on XNS. It differs by one significant field. The SAP (Service Advertisement Protocol) in IPX comed directly from XNS. So you are agreeing with me that to use netns to do ipx when we have netipx does not make sense? :-) FWIW. I know, a lot of my time went into netipx, which was derived from netns. I also did IPXrouted which does SAP too. I was mostly agreeing with Julian, that if people are using it, it shouldn't be orphaned because something moved out from under some otherwise perfectly good code. A lot of people used to do 802.3 vs. Ethernet II, as well, and they did it for compatability with legacy systems... so whether it makes technical sense or not, it might make business sense. 8-). You can tell them it makes business sense to do a s/AF_NS/AF_IPX/g in their code and suddenly they will be able to do even more then before, for instance they will be able to do different frame types on the same wire and one different wires. The netns code can only do one frame type per box, which is a pain if you want to connect part 802.3 and part Ethernet II networks. Yes I know because we run it like that at work. As a bonus FreeBSD get to maintain one piece of code and not two pieces that do almost exactly the same thing. Bugs fixed in one place, enhancements made in one place. I'm sure it makes business sense. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Release building broken for -current
when bulding release on -current I get (since a couple of days): rm -rf /R/stage/dists mkdir -p /R/stage/dists rolling base/base tarball mtree: line 0: dumpdates: No such file or directory *** Error code 1 Stop in /usr/src/release. Somehow dumpdates didn't get installed into /R/stage/trees/base/usr/share/examples/etc md5 died on zero length files. You will have to upgrade the machine or at least do a buildworld with new source before you try a release again. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3 floppy system for -current releases
This has been committed already, but I'll answer your questions. If
you are unhappy with anything, go ahead and change it. At the end I
thought it more usefull to have snapshots that complete the building
process, than ones that don't. People can test and give feedback on
something that exists.
On 08-Aug-2002 John Hay wrote:
Here is a try at a 3 floppy system. Most people should be able to
install with the first 2 floppies (kern.flp and mfsroot.flp). Just
those that need a driver on the third floppy (drivers.flp) will
need it.
If this idea is acceptable, we should probably tweak what should
go on the second floppy and what is used the least and put that
on the last one.
To load drivers from the drivers floppy, go to Configure and then
the last option there is Load KLD.
The last 2 files in the diff (bld-ko.sh and driver-list.awk) are not
really needed. That is part of my attempt to create a single .ko to
save space on mfsroot.flp. But I can't get internal dependancies to
work yet. Most drivers depend on miibus and that don't get loaded
first.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
Index: usr.sbin/sysinstall/system.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/system.c,v
retrieving revision 1.119
diff -u -r1.119 system.c
--- usr.sbin/sysinstall/system.c 1 Nov 2001 23:32:46 - 1.119
+++ usr.sbin/sysinstall/system.c 8 Aug 2002 09:17:01 -
@@ -348,7 +348,13 @@
snprintf(buf, FILENAME_MAX, /stand/help/%s.hlp.gz, file);
if (file_readable(buf))
return expand(buf);
+snprintf(buf, FILENAME_MAX, /stand/help/%s.hlp, file);
+if (file_readable(buf))
+ return expand(buf);
snprintf(buf, FILENAME_MAX, /stand/help/%s.TXT.gz, file);
+if (file_readable(buf))
+ return expand(buf);
+snprintf(buf, FILENAME_MAX, /stand/help/%s.TXT, file);
if (file_readable(buf))
return expand(buf);
snprintf(buf, FILENAME_MAX, /usr/src/usr.sbin/sysinstall/help/%s.hlp, file);
What does this patch do? It calls expand() so it is expecting an
uncompressed file which is probably wrong.
The diff show too little content. If you look at that place in the
file, you will see there are others that are the same. That expand()
function only expands when the file has been compressed. It behaves
like zcat -f.
Index: release/Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.698
diff -u -r1.698 Makefile
--- release/Makefile 5 Aug 2002 16:57:43 - 1.698
+++ release/Makefile 8 Aug 2002 15:40:27 -
@@ -518,7 +518,8 @@
.endif
cd ${j}_crunch; ${WMAKE} -f ${j}_crunch.mk subclean
cd ${.CURDIR}/..; ${TMAKE} build-tools
- cd ${j}_crunch; ${WMAKE} -f ${j}_crunch.mk all
+ cd ${j}_crunch; ${WMAKE} -f ${j}_crunch.mk \
+ CFLAGS=-Os -pipe -DNO_CPU_CFLAGS all
mv ${j}_crunch/${j}_crunch ${RD}/crunch/${j}
.endfor
touch release.5
@@ -654,15 +655,15 @@
${RD}/mfsfd/stand/etc/services
ln ${RD}/mfsfd/stand/etc/services ${RD}/mfsfd/etc/services
ln ${RD}/mfsfd/stand/etc/netconfig ${RD}/mfsfd/etc/netconfig
- gzip -9c ${RD}/trees/base/COPYRIGHT ${RD}/mfsfd/stand/help/COPYRIGHT.hlp.gz
+ cat ${RD}/trees/base/COPYRIGHT ${RD}/mfsfd/stand/help/COPYRIGHT.hlp
.if !defined(NODOC)
@for i in ${DIST_DOCS_ARCH_INDEP}; do \
- gzip -9c ${RND}/${RELNOTES_LANG}/$$i/article.txt
${RD}/mfsfd/stand/help/`echo $${i} | tr
'a-z' 'A-Z'`.TXT.gz; \
+ cat ${RND}/${RELNOTES_LANG}/$$i/article.txt ${RD}/mfsfd/stand/help/`echo
$${i} | tr
'a-z'
'A-Z'`.TXT; \
done
@for i in ${DIST_DOCS_ARCH_DEP}; do \
- gzip -9c ${RND}/${RELNOTES_LANG}/$$i/${TARGET}/article.txt
${RD}/mfsfd/stand/help/`echo
$${i} | tr 'a-z' 'A-Z'`.TXT.gz; \
+ cat ${RND}/${RELNOTES_LANG}/$$i/${TARGET}/article.txt
${RD}/mfsfd/stand/help/`echo
$${i} |
tr 'a-z' 'A-Z'`.TXT; \
done
- @mv ${RD}/mfsfd/stand/help/INSTALLATION.TXT.gz
${RD}/mfsfd/stand/help/INSTALL.TXT.gz
+ @mv ${RD}/mfsfd/stand/help/INSTALLATION.TXT
${RD}/mfsfd/stand/help/INSTALL.TXT
.endif
-test -f ${.CURDIR}/install.cfg cp ${.CURDIR}/install.cfg ${RD}/mfsfd
@mkdir -p ${RD}/mfsfd/boot
@@ -674,16 +675,28 @@
@echo Making the regular boot floppy.
@tar --exclude CVS -cf - -C ${.CURDIR}/../usr.sbin/sysinstall help | \
tar xf - -C ${RD}/mfsfd/stand
- @echo Compressing doc files...
- @gzip -9 ${RD}/mfsfd/stand/help/*.hlp
Why in the world are you not compressing the various text files? I thought the name
of the game was to _decrease_ the size of things on the floppies.
Because you get better returns if you compress them once at the end
Re: VM panic
If I do a make -jN world build on my dual MMX/200 box, I usually end up in tears (well, a panic anyway). This is completely reproducible, and the panic always happens in swapout_procs while vmdaemon is running. Anyone else getting this? What kind of value do you use for N? It looks like lately the makefiles are too aggressive when using -j, so you end up with N * N * 2 processes running simultaneously. On my -current box with 128M RAM, I used -j13 for a long time, but that runs out of swap nowadays, so I'm using -j4 which does work. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Makefile.inc1 warning
On Fri, Aug 09, 2002 at 07:41:44AM +0200, John Hay wrote: Hi Ruslan, During make release I see a lot of these messages: # make: no target to make. /usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/shar e/mk CPUTYPE=i386 -V CPUTYPE returned non-zero status make: no target to make. /usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/shar e/mk CPUTYPE=i386 -V CPUTYPE returned non-zero status ## There was a bug in make(1) that got fixed in make/main.c,v 1.68. Because these warning are harmless, I decided to not force the upgrade of installed make(1) in this case from src/Makefile. (This was already reported on -current on August 7, in the Makefile.inc1 thread, and a similar reply.) I missed the part that it was a make problem. I saw a commit to Makefile.inc1 and after that I still had the problem. :-/ I'll update make and try again. Thanks. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3 floppy system for -current releases
Ruslan,
Here is my latest version. It has all the changes you requested and
a fix for the case where there isn't a third floppy.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
Index: usr.sbin/sysinstall/system.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/system.c,v
retrieving revision 1.119
diff -u -r1.119 system.c
--- usr.sbin/sysinstall/system.c1 Nov 2001 23:32:46 - 1.119
+++ usr.sbin/sysinstall/system.c8 Aug 2002 09:17:01 -
@@ -348,7 +348,13 @@
snprintf(buf, FILENAME_MAX, /stand/help/%s.hlp.gz, file);
if (file_readable(buf))
return expand(buf);
+snprintf(buf, FILENAME_MAX, /stand/help/%s.hlp, file);
+if (file_readable(buf))
+ return expand(buf);
snprintf(buf, FILENAME_MAX, /stand/help/%s.TXT.gz, file);
+if (file_readable(buf))
+ return expand(buf);
+snprintf(buf, FILENAME_MAX, /stand/help/%s.TXT, file);
if (file_readable(buf))
return expand(buf);
snprintf(buf, FILENAME_MAX, /usr/src/usr.sbin/sysinstall/help/%s.hlp, file);
Index: release/Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.698
diff -u -r1.698 Makefile
--- release/Makefile5 Aug 2002 16:57:43 - 1.698
+++ release/Makefile8 Aug 2002 20:04:08 -
@@ -518,7 +518,8 @@
.endif
cd ${j}_crunch; ${WMAKE} -f ${j}_crunch.mk subclean
cd ${.CURDIR}/..; ${TMAKE} build-tools
- cd ${j}_crunch; ${WMAKE} -f ${j}_crunch.mk all
+ cd ${j}_crunch; ${WMAKE} -f ${j}_crunch.mk \
+ CFLAGS=-Os -pipe -DNO_CPU_CFLAGS all
mv ${j}_crunch/${j}_crunch ${RD}/crunch/${j}
.endfor
touch release.5
@@ -654,15 +655,15 @@
${RD}/mfsfd/stand/etc/services
ln ${RD}/mfsfd/stand/etc/services ${RD}/mfsfd/etc/services
ln ${RD}/mfsfd/stand/etc/netconfig ${RD}/mfsfd/etc/netconfig
- gzip -9c ${RD}/trees/base/COPYRIGHT ${RD}/mfsfd/stand/help/COPYRIGHT.hlp.gz
+ cp ${RD}/trees/base/COPYRIGHT ${RD}/mfsfd/stand/help/COPYRIGHT.hlp
.if !defined(NODOC)
@for i in ${DIST_DOCS_ARCH_INDEP}; do \
- gzip -9c ${RND}/${RELNOTES_LANG}/$$i/article.txt
${RD}/mfsfd/stand/help/`echo $${i} | tr 'a-z' 'A-Z'`.TXT.gz; \
+ cp ${RND}/${RELNOTES_LANG}/$$i/article.txt ${RD}/mfsfd/stand/help/`echo
+$${i} | tr 'a-z' 'A-Z'`.TXT; \
done
@for i in ${DIST_DOCS_ARCH_DEP}; do \
- gzip -9c ${RND}/${RELNOTES_LANG}/$$i/${TARGET}/article.txt
${RD}/mfsfd/stand/help/`echo $${i} | tr 'a-z' 'A-Z'`.TXT.gz; \
+ cp ${RND}/${RELNOTES_LANG}/$$i/${TARGET}/article.txt
+${RD}/mfsfd/stand/help/`echo $${i} | tr 'a-z' 'A-Z'`.TXT; \
done
- @mv ${RD}/mfsfd/stand/help/INSTALLATION.TXT.gz
${RD}/mfsfd/stand/help/INSTALL.TXT.gz
+ @mv ${RD}/mfsfd/stand/help/INSTALLATION.TXT ${RD}/mfsfd/stand/help/INSTALL.TXT
.endif
-test -f ${.CURDIR}/install.cfg cp ${.CURDIR}/install.cfg ${RD}/mfsfd
@mkdir -p ${RD}/mfsfd/boot
@@ -674,16 +675,23 @@
@echo Making the regular boot floppy.
@tar --exclude CVS -cf - -C ${.CURDIR}/../usr.sbin/sysinstall help | \
tar xf - -C ${RD}/mfsfd/stand
- @echo Compressing doc files...
- @gzip -9 ${RD}/mfsfd/stand/help/*.hlp
.if ${TARGET_ARCH} == alpha
rm -rf ${RD}/mfsfd/stand/help/*
.endif
.if exists(${.CURDIR}/${TARGET}/drivers.conf)
@mkdir -p ${RD}/mfsfd/stand/modules
- @awk -f ${.CURDIR}/scripts/driver-copy2.awk \
+ @awk -f ${.CURDIR}/scripts/driver-copy2.awk 2 \
${.CURDIR}/${TARGET}/drivers.conf \
${RD}/trees/base/boot/kernel ${RD}/mfsfd/stand/modules
+ -@rm -rf ${RD}/driversfd
+ @mkdir ${RD}/driversfd
+ @awk -f ${.CURDIR}/scripts/driver-copy2.awk 3 \
+ ${.CURDIR}/${TARGET}/drivers.conf \
+ ${RD}/trees/base/boot/kernel ${RD}/driversfd
+ -@rmdir ${RD}/driversfd
+ [ -d ${RD}/driversfd ] sh -e ${.CURDIR}/scripts/doFS.sh \
+ ${RD}/floppies/drivers.flp ${RD} ${MNT} ${BOOTSIZE} \
+ ${RD}/driversfd ${BOOTINODE} ${BOOTLABEL}
.endif
sh -e ${.CURDIR}/scripts/doFS.sh -s mfsroot ${RD} ${MNT} \
${MFSSIZE} ${RD}/mfsfd ${MFSINODE} ${MFSLABEL}
@@ -963,7 +971,8 @@
cd ${.CURDIR}/..; \
KERNEL_KO=BOOTMFS KODIR= \
${CROSSMAKE} ${KERNEL_FLAGS} -DNO_MODULES -DNO_KERNELCLEAN \
- KERNCONF=BOOTMFS buildkernel reinstallkernel \
+ KERNCONF=BOOTMFS COPTFLAGS=-Os -pipe -DNO_CPU_COPTFLAGS \
+ buildkernel reinstallkernel \
DESTDIR=${RD}/kernels
[ -r ${.CURDIR}/../sys/${TARGET}/conf/BOOTMFS.hints ] \
cp ${.CURDIR}/../sys/${TARGET}/conf/BOOTMFS.hints ${RD}/kernels
@@ -995,6 +1004,7 @@
.endif
@echo load -t mfs_root /mfsroot ${RD}/image.${FSIMAGE}/boot/loader.rc
@echo set
Re: 3 floppy system for -current releases
I think MSDOS installs are pretty rare and NFS ones even rarer (FTP is easier to setup) I've had one recent example here where FTP wouldn't work, but NFS flew. Weird but I can appreciate it's possible. I'm wondering if that was because something in our stack was bust or because of some firewall or other network thing? I wasn't suggesting removing NFS install support, but giving it a lower priority as I suggest that numerically more people do FTP installs. I have no evidence to back my claim though. I have only my own experience nad can say that I have never done a nfs install, but have done lots of ftp installs and occasionally a cd install. So should I commit the code and let us tune what go on which floppy later or should I just sit back and enjoy the ride? I'm not worried too much because the snaps on ftp.za.freebsd.org is working again. :-) ... Yes they are non-standard (they use my patch) but at least they exist, while without the patch there are no snaps. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3 floppy system for -current releases
Hi Terry, Why?? I disagree. CD9600 can go to the 3rd floppy -- if I am installing from floppy's I am 99.9% chance doing a network install. I have an idea... If you only support installing via whatever option wins a vote as The One True Way, then there'll be a 100% chance that that's the way that people will install because that will be the only way that works. ... Is there a particularly good reason people should rip code out, and thereby limit FreeBSD's potential market? Calm down and relax. Which part of my patch removed support for anything that might be needed during the install? ... Well thinking about it again, you just might have something there. It is not as if M$ give you many options of how you want to install and still people are buying Windows at a high enough rate that Bill is pretty rich. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Makefile.inc1 warning
Hi Ruslan, During make release I see a lot of these messages: # make: no target to make. /usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/shar e/mk CPUTYPE=i386 -V CPUTYPE returned non-zero status make: no target to make. /usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/shar e/mk CPUTYPE=i386 -V CPUTYPE returned non-zero status ## John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rc.d/bootparams patch
Hi Gordon,
This patch seems to make bootparamd work on my machine.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
--- /usr/src/etc/rc.d/bootparamsFri Jun 14 00:14:36 2002
+++ bootparams Sat Aug 3 10:24:44 2002
@@ -11,8 +11,8 @@
. /etc/rc.subr
name=bootparamd
-rcvar=$name
-command=/usr/sbin/rpc.${name}
+rcvar=`set_rcvar`
+command=/usr/sbin/${name}
required_files=/etc/bootparams
load_rc_config $name
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
-current upgrade path broken?
Should one be able to do a source upgrade from an old -current (March 10) to the latest? I have been trying, but it breaks in the cross tools section in gnu/usr.bin/cc/cc_int. mkdep fails. There are a lot of warnings that looks like this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:70: warning: `TARGET_DEFAULT' redefined /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:400: warning: this is the location of the previous definition /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:83: warning: `FUNCTION_VALUE_REGNO_P' redefined /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:1654: warning: this is the location of the previous definition ## I don't think they cause the failure, but there are so many of them that they are hiding the real stuff. I think what is breaking mkdep is this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:598: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:3400: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:4006: macro `SELECT_RTX_SECTION' used with too many (3) args ... mkdep: compile failed *** Error code 1 Stop in /home/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /home/src/gnu/usr.bin/cc. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current upgrade path broken?
Yup, you are right, thanks. I remember about the problem, but did not remember the symptoms of it, so didn't put two and two together. :-( I have stumbled to this too, and thought I'm getting crazy. After some hours of investigation, I have found that O'Brien did some repo-surgery there, removed some revisions, and later replaced them with the new stuff (well, new stuff took the same revisions), and now some of your checked out sources (revisions) do not match what's in your CVS repository. rm -rf /usr/src/contrib/gcc and /usr/src/gnu/usr.bin/cc, check them out again, and try again. It worked for me now. I hope that people will learn the lessons from this, and won't be doing such scary things in the future. Peter had some work-arounds to avoid problems like this, were these forced commits over the affected files, I don't remember? ... I don't think they cause the failure, but there are so many of them that they are hiding the real stuff. I think what is breaking mkdep is this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:598: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:3400: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:4006: macro `SELECT_RTX_SECTION' used with too many (3) args ... mkdep: compile failed ... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
setting TARGET_ARCH breaks ghostscript in make release
It looks like the change in release/Makefile to add TARGET_ARCH breaks the build of ghostscript-gnu. Actually just setting the TARGET_ARCH environment variable and then trying to build print/ghostscript-gnu will break: beast:/usr/ports/print/ghostscript-gnu # setenv TARGET_ARCH=i386 beast:/usr/ports/print/ghostscript-gnu # make -DWITHOUT_X11 -DBATCH ... gmake[2]: Entering directory `/usr/ports/print/ghostscript-gnu/work/ghostscript-7.05/gimp-print-4.2.1' gmake[2]: Nothing to be done for `all-am'. gmake[2]: Leaving directory `/usr/ports/print/ghostscript-gnu/work/ghostscript-7.05/gimp-print-4.2.1' gmake[1]: Leaving directory `/usr/ports/print/ghostscript-gnu/work/ghostscript-7.05/gimp-print-4.2.1' creating symlinks for gimp-print ... creating symlinks for md2k ... creating symlinks for alps ... creating symlinks for bj10v ... creating symlinks for lips ... building epag utility ... cc -O -pipe i386= -c -o ert.o ert.c cc: cannot specify -o with -c or -S and multiple compilations gmake: *** [ert.o] Error 1 *** Error code 2 Stop in /usr/ports/print/ghostscript-gnu. beast:/usr/ports/print/ghostscript-gnu # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote: ru Moved vx(4) and all miibus consumers (including miibus) out ru from kern.flp to mfsroot.flp. This leaves 9K of the free ru space for kern.flp. Yey! 5-current distribution will come back again, thank you! This was broken again. I don't have any ideas of what to move out. For my releases I just took MSDOSFS and NFSCLIENT out of the kernel, but my release broke again just now because mfsroot.flp is full. :-( John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
On Wed, Jul 24, 2002 at 08:07:11PM +0200, John Hay wrote: On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote: ru Moved vx(4) and all miibus consumers (including miibus) out ru from kern.flp to mfsroot.flp. This leaves 9K of the free ru space for kern.flp. Yey! 5-current distribution will come back again, thank you! This was broken again. I don't have any ideas of what to move out. For my releases I just took MSDOSFS and NFSCLIENT out of the kernel, This is not an option, sorry. Well, I did say for mine. :-) For mine it is an option. :-) nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can reside somewhere else. but my release broke again just now because mfsroot.flp is full. :-( Duh! We can save some space (I think) by not gziping the individual help files, but leave them unzipped. Then the final gzip of the whole image should be able to do a better job of it. But I doubt if it will give us enough room for nfsclient.ko and msdosfs.ko. :-/ Maybe we should start a third floppy which contains the lesser used stuff. No I'm not volunteering. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
could sleep with inp locked
After the recent locking working in netinet, I get this message everytime I login to the -current machine using ssh over ipv6. I don't see it if I use ipv4. ../../../vm/uma_core.c:1327: could sleep with inp locked from ../../../netinet/tcp_usrreq.c:536 PS. That don't mean there are not hundreds of other could sleep messages. There are, but the inp one is new. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Fri, Jun 07, 2002 at 11:26:18PM -0700, Bill Fenner wrote: I ran use.perl port, and that gave me a working perl for mergemaster. Interestingly, use.perl system didn't give me back the perl wrapper; I'm not sure what I got. Sigh. That script predates the removal of perl from the base system, and was supposed to facilitate the switching between various perl versions. It still has its justification of existence on -STABLE, but on -CURRENT, it does not work well any more. What you got is likely links to nowhere, your perl wrapper binary was clobbered. Bottom line: if at all, it should only be used for use.perl port, for the cases where the wrapper does not work as desired. Or maybe we should get rid of the wrapper and change the perl port/package to run use.perl port by default on current? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
what happened to softintr?
A GENERIC kernel on current fails to compile missing softintr. # beast:/sys/i386/compile/GENERIC # make -DNO_MODULES -DNO_WERROR cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/ncv/ncr53c500.c ../../../dev/ncv/ncr53c500.c: In function `ncv_world_start': ../../../dev/ncv/ncr53c500.c:503: warning: implicit declaration of function `softintr' cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/nsp/nsp.c ../../../dev/nsp/nsp.c: In function `nsp_world_start': ../../../dev/nsp/nsp.c:495: warning: implicit declaration of function `softintr' cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/stg/tmc18c30.c ../../../dev/stg/tmc18c30.c: In function `stg_world_start': ../../../dev/stg/tmc18c30.c:377: warning: implicit declaration of function `softintr' sh ../../../conf/newvers.sh GENERIC cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding vers.c linking kernel.debug ncr53c500.o: In function `ncv_world_start': ../../../dev/ncv/ncr53c500.c:503: undefined reference to `softintr' nsp.o: In function `nsp_world_start': ../../../dev/nsp/nsp.c:495: undefined reference to `softintr' tmc18c30.o: In function `stg_world_start': ../../../dev/stg/tmc18c30.c:377: undefined reference to `softintr' *** Error code 1 Stop in /usr/src/sys/i386/compile/GENERIC. # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl script rewrites - progress (2)
I just upgraded my machine, removed perl as far as I could find it, and
tried to rebuild perl from the ports tree.
So far, I had to change the Makefile first, since it used perl for the
post-patch target. That was easy:
change the CP and the PERL -pi to a:
${SED} ${FILES}/use.perl $WRKDIR/use.perl
But so far it doesn't compile :-(
Anyone else seeing this?
Me too. :-( The error I see is:
###
Extracting splain (with variable substitutions)
../miniperl -I../lib perlcc.PL
Extracting perlcc (with variable substitutions)
../miniperl -I../lib dprofpp.PL
Extracting dprofpp (with variable substitutions)
Making x2p stuff
make: don't know how to make built-in. Stop
*** Error code 2
Stop in /usr/ports/lang/perl5/work/perl-5.6.1.
*** Error code 1
Stop in /usr/ports/lang/perl5.
###
###
grep built-in work/perl-5.6.1/x2p/makefile
hash$(OBJ_EXT): built-in
str$(OBJ_EXT): built-in
util$(OBJ_EXT): built-in
walk$(OBJ_EXT): built-in
###
No more perl in the base, perl in ports don't build. Hmmm Who said
there wasn't a conspiracy against perl? :-)
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
perl build broken on current. Was: Re: Perl script rewrites - progress (2)
I just upgraded my machine, removed perl as far as I could find it, and
tried to rebuild perl from the ports tree.
So far, I had to change the Makefile first, since it used perl for the
post-patch target. That was easy:
change the CP and the PERL -pi to a:
${SED} ${FILES}/use.perl $WRKDIR/use.perl
But so far it doesn't compile :-(
Anyone else seeing this?
This fix the perl build for me on current. The last part of the patch
is a litlle brute force. For some reason the temporary dependancy file
end up with lines built-in and command line in them, so I just
removed them in one of the sed invocations. I wasn't really interested
in where they come from. I wanted a working perl, and didn't care much
about a nice port. :-)
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/ncvs/ports/lang/perl5/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- Makefile19 Dec 2001 17:05:04 - 1.40
+++ Makefile19 May 2002 18:53:53 -
@@ -119,12 +119,11 @@
BSDPAN_WRKSRC= ${WRKDIR}/BSDPAN-${PORTVERSION}
post-patch:
- ${CP} ${FILESDIR}/use.perl ${WRKDIR}
- ${PERL} -pi -e 's|%%PREFIX%%|${PREFIX}|g;' \
- -e 's|%%PERL_VER%%|${PERL_VER}|g;' \
- -e 's|%%PERL_VERSION%%|${PERL_VERSION}|g;' \
- -e 's|%%PERL_ARCH%%|${PERL_ARCH}|g;' \
- ${WRKDIR}/use.perl
+ ${SED} -e 's|%%PREFIX%%|${PREFIX}|g' \
+ -e 's|%%PERL_VER%%|${PERL_VER}|g' \
+ -e 's|%%PERL_VERSION%%|${PERL_VERSION}|g' \
+ -e 's|%%PERL_ARCH%%|${PERL_ARCH}|g' \
+ ${FILESDIR}/use.perl ${WRKDIR}/use.perl
post-install:
@strip ${PREFIX}/bin/perl ${PREFIX}/bin/suidperl
Index: files/patch-ae
===
RCS file: /home/ncvs/ports/lang/perl5/files/patch-ae,v
retrieving revision 1.5
diff -u -r1.5 patch-ae
--- files/patch-ae 22 Mar 2001 15:17:46 - 1.5
+++ files/patch-ae 19 May 2002 18:19:11 -
@@ -1,5 +1,5 @@
makedepend.SH.ORIG Fri Jul 24 06:00:58 1998
-+++ makedepend.SH Thu Jul 30 17:08:37 1998
+--- makedepend.SH.orig Mon Mar 19 09:33:17 2001
makedepend.SH Sun May 19 20:19:01 2002
@@ -68,6 +68,7 @@
case $osname in
os2) ;;
@@ -8,3 +8,15 @@
*) $touch $firstmakefile ;;
esac
fi
+@@ -196,8 +197,9 @@
+ $echo Updating $mf...
+ $echo # If this runs make out of memory, delete /usr/include lines. \
+$mf.new
+-$sed 's|^\(.*\$(OBJ_EXT):\) *\(.*/.*\.c\) *$|\1 \2; '$defrule \2| .deptmp \
+- $mf.new
++$sed -e '/built-in/d' -e '/command line/d' \
++ -e 's|^\(.*\$(OBJ_EXT):\) *\(.*/.*\.c\) *$|\1 \2; '$defrule \2| \
++ .deptmp $mf.new
+ else
+ $MAKE hlist || ($echo Searching for .h files...; \
+ $echo *.h | $tr ' ' $trnl | $egrep -v '\*' .hlist)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Is current 'safe' to play in again [post GCC changes/stability]
Fwiw, with tonight's -current I am seeing cc -O -pipe -march=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DTERM_EMU -I/disk0/usr/src/sys/boot/i386/libi386/../../common -I/disk0/usr/src/sys/boot/i386/libi386/../btx/lib -I/disk0/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica -I/disk0/usr/src/sys/boot/i386/libi386/../../.. -I. -I/disk0/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -c /disk0/usr/src/sys/boot/i386/libi386/bioscd.c -o bioscd.o /disk0/usr/src/sys/boot/i386/libi386/bioscd.c: In function `bc_strategy': /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: `DEV_BSIZE' undeclared (first use in this function) /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: (Each undeclared identifier is reported only once /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: for each function it appears in.) *** Error code 1 Stop in /disk0/usr/src/sys/boot/i386/libi386. *** Error code 1 I think changing '#include machine/param.h' to '#include sys/param.h' should be enough. DEV_BSIZE moved to sys/param.h, but it looks like it wasn't make world tested. :-( John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
makefiles broken with make -j?
Hi, It looks like the makefiles are a bit broken if make -j13 is used. What I see here is that osreldate.h in obj/usr/src/i386/usr/include/ looks like this: ... #ifdef _KERNEL #ifdef _KERNEL #error /usr/include/osreldate.h cannot be used in the kernel, use sys/param.h #error /usr/include/osreldate.h cannot be used in the kernel, use sys/param.h #else #else #undef __FreeBSD_version #undef __FreeBSD_version #define __FreeBSD_version 500035 #define __FreeBSD_version 500035 #endif #endif When looking at the output of make -j13 world, it looks like some parts are being run more than once: -- stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORM AT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/li bdata/perl/5.6.1 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH= /usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i38 6/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/inst all.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/ obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 S HARED=symlinks includes incsinstall === share/info === share/info === include === include Setting up symlinks to kernel source tree... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fast playback with Intel 82801BA (ICH2)
| -current compiled today mp3s play too fast, any ideas on how to | diagnose this? | | pcm0: Intel 82801BA (ICH2) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device | 31.5 on pci0 | pcm0: measured ac97 link rate at 44061 Hz This makes it sound almost perfect: sysctl hw.snd.pcm0.ac97rate=55000 the default 44061 is bad. What about 56000? Our Dells seem to use it. I'm not sure what is so magic about it. Maybe they wanted to cater for modems on the ac97 channel. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new expr(1) behaviour breaks libtool
I have just committed code to expr which will cause it to behave more like the old expr did in the presence of an EXPR_COMPAT environment variable. Ports can then be set up to build with this variable defined until the libtool maintainers fix up their act. Thanks, with this and some patches to the ghostscript-gnu and jade ports, I can now build releases with docs. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
new expr(1) behaviour breaks libtool
Hi, I see the new new behaviour of expr(1) requires you to add '--' if your commandline arguments might start with a '-'. This does break things a little because our old expr(1) does not understand a '--' in the beginning and the new one don't work right without it. :-((( The place where I noticed it was when libtool started to complain when compiling jade. Libtool does things like: expr -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -lsp : -l\(.*\) expr -lm : -l\(.*\) expr -lgrove : -l\(.*\) On -current this now have to be: expr -- -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -- -lsp : -l\(.*\) expr -- -lm : -l\(.*\) expr -- -lgrove : -l\(.*\) If we are going to leave this behaviour, we will have to teach libtool how to call expr(1) differently on -stable and -current and it looks like yet again different from the rest of the world. :-((( Yes, I did read the commit message, but I still think the behaviour of the new expr(1) is wrong. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new expr(1) behaviour breaks libtool
I see the new new behaviour of expr(1) requires you to add '--' if your commandline arguments might start with a '-'. This does break things a little because our old expr(1) does not understand a '--' in the beginning and the new one don't work right without it. :-((( I'm almost positive this issue was discussed before. Check the follow ups to the commit. The only one I could find was in -current, where Kris asked if w3m or expr is to blame and Garrett said w3m is to blame. The place where I noticed it was when libtool started to complain when compiling jade. Libtool does things like: expr -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -lsp : -l\(.*\) expr -lm : -l\(.*\) expr -lgrove : -l\(.*\) On -current this now have to be: expr -- -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -- -lsp : -l\(.*\) expr -- -lm : -l\(.*\) expr -- -lgrove : -l\(.*\) If we are going to leave this behaviour, we will have to teach libtool how to call expr(1) differently on -stable and -current and it looks like yet again different from the rest of the world. :-((( This should exactly match the behavior of any certified UNIX system. Well libtool is still broken, so maybe if systems like that do exist, they don't need libtool? :-))) Yes, I did read the commit message, but I still think the behaviour of the new expr(1) is wrong. Not according to the Standard, or the response from Garrett's request for clarification of the Standard. H. I can understand the requirement to eat '--', but to throw a tantrum just because the commandline started with a '-' is a little too much. BTW, was the response posted somewhere? I searched through -standards, -commit and -current but couldn't find it. Maybe I just didn't ask the right question to the search engine or maybe it was in another list. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no current snapshots available
there are no up to date current snapshots available. At ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/ the last snapshot is from 21-Mar-2002 and at ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snapshots/i386/ the last snapshot is from 23-Mar-2002 (apparently disk full). If you have enough patience, you can get snapshots from ftp.za.freebsd.org/pub/FreeBSD/snapshots/i386/ Our link is only 2Mbit/s, so don't expect US speeds. :-) I'm building the fixit floppy without a populated /dev. That leaves enough space open to fit all the rest of the stuff and it shouldn't be needed on -current because of devfs. But I haven't tried it. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB printing broken?
I've a kernel from Mar 27 which isn't able to print with my USB printer.
usbdevs hangs hard ('.vd' is a typo, I wanted to use '-vd'):
---snip---
netchild 14525 0.0 0.7 4152 427 p0 D+4:13pm 0:00.02 usbdevs .vd
---snip---
ulpt0: Hewlett-Packard DeskJet 895C, rev 1.00/1.00, addr 3, iclass 7/1
ulpt0: using bi-directional mode
Is anyone out there able to reproduce this?
A Mar 12 kernel works just fine.
A kernel from Mar 19 also does not work for me. Usbdevs doesn't hang but
printing just doesn't happen. It just stays in the queue. When I tried
to print a test page from the SETUP program that comes with apsfilter,
it either hangs forever or just says that /dev/ulpt0 is busy. My printer
is:
ulpt0: Hewlett-Packard DeskJet 840C, rev 1.00/1.00, addr 3, iclass 7/1
ulpt0: using bi-directional mode
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
fixit.flp full again
A make release breaks because the fixit floppy is too big again. So what can we do to get it smaller? Anybody got any ideas or shall we just choose a random utility and delete it? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fixit.flp full again
A make release breaks because the fixit floppy is too big again. So what can we do to get it smaller? Anybody got any ideas or shall we just choose a random utility and delete it? I think that we really should move to using new loader(8) feature for loading kernels/modules split across several physical medias. See cvs logs for src/lib/libstand/splitfs.c for details. Uhm, but splitting kernels and modules won't help the fixit floppy? Or am I missing something? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
acquiring duplicate lock of same type
I have seen these messages on my slow 266MHz dual Pentium II machine with a kernel build with source from after Matt and Jake's commits. Is there anyone interrested in it? It happened while doing a cvs -q update -PAd. acquiring duplicate lock of same type: PCPU KNOTE 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU PIPE 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU NAMEI 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU Files 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 65536 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 32768 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 16384 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 8192 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 4096 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 2048 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 1024 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 512 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 256 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 128 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 64 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 32 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU 16 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: PCPU MAP ENTRY 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT, make buildworld break?
I see that here too. Maybe des missed something during his openpam upgrade? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] I upgraded frem 4.5-STABLE to 5.0-CURRENT three days ago, and it worked fine. But since I cvsupped yesterday, a 'make buildworld' results in: ** snip snip ** cc -pg -O -pipe -I/usr/src/lib/libpam/libpam -I/usr/src/lib/libpam/libpam/../.. /../contrib/openpam/include -DLIB_MAJ=2 -Werror -Wall -W -Wstrict-prototypes -Wm issing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wsw itch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/libpam/pam _std_option.c -o pam_std_option.po make: don't know how to make openpam_static_modules.po. Stop *** Error code 2 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 ** snip snip ** I've tried several times, each time with a clean /usr/obj. Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is any patch to situation with bad linking library on -CURRENT?
I'm sorry for possible beginning of flame, but is there exist real solution for bad linking library problem on -CURRENT? I was noticed about this problem about two or three weeks ago, and don't see nothing except discussions about new binutils. It looks like the import for binutils today fixed it. At least my test case of libpng does not coredump anymore. I'll see how far a release gets. It will probably not finish because I think the dhcp stuff in the crunch files are still broken. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel compile error with today's cvsup.
On my daily build, my kernels are broken as per log: === wi cd /usr/obj/usr/src/sys/PIII850N; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make - f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N cc -O -pipe -I/usr/include -I.-c aicasm_gram.c cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cc1': No such file or directory *** Error code 1 I don't think it is the kernel. My make release failed with the same type of error and that machine's kernel is from Jan 28. Maybe it is the search path that changed in gnu/usr.bin/cc/cc_tools/freebsd-native.h ... Just a guess. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release failure in kerberos
Hi Jacques, Make release fails here. Can it be your changes to kerberos? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] === libexec/kdc ... cc -O -pipe -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/include -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/hdb -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kuser -I/usr/obj/usr/src/kerberos5/libexec/kdc/../../lib/libasn1 -I/usr/obj/usr/src/kerberos5/libexec/kdc/../../lib/libhdb -I/usr/obj/usr/src/kerberos5/libexec/kdc -Wall -I/usr/src/kerberos5/libexec/kdc/../../include -I/usr/src/kerberos5/libexec/kdc/../../include -DHAVE_CONFIG_H -DINET6-c /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function `create_reply_ticket': /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:254: syntax error before `ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: warning: implicit declaration of function `krb_create_ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: `ticket' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: (Each undeclared identifier is reported only once /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: for each function it appears in.) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:282: warning: implicit declaration of function `krb_life_to_time' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function `do_authenticate': /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:405: `v4_realm' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:407: warning: implicit declaration of function `db_fetch4' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:435: warning: implicit declaration of function `get_des_key' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:483: warning: implicit declaration of function `krb_time_to_life' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function `do_getticket': /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:587: `ANAME_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:588: `INST_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:589: `REALM_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:599: `v4_realm' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:646: syntax error before `ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:651: `SNAME_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:654: `ticket' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:666: warning: implicit declaration of function `decomp_ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:651: warning: unused variable `sinstance' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:650: warning: unused variable `sname' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:589: warning: unused variable `prealm' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:588: warning: unused variable `pinst' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:587: warning: unused variable `pname' *** Error code 1 Stop in /usr/src/kerberos5/libexec/kdc. *** Error code 1 Stop in /usr/src/kerberos5/libexec. *** Error code 1 Stop in /usr/src/kerberos5. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /home/src/release. End Thu Feb 21 01:27:59 SAST 2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Not committing WARNS settings...
All David has to do is set WARNS=0 or NO_WERROR=1 in bsd.sys.mk or /etc/defaults/make.conf temporarily when he tests and commits the changeover, and he'll sidestep all the problems. There's no need to impose restrictions on the activities of other committers. It's really not a big deal, IMO. Kris Let me hijack this a little. How many of you WARNS= adding people consider different compile/code paths than the one your machine exercise? For instance the one make release will exercise? The WARNS=1 in libexec/Makefile.inc breaks make release because telnetd is then compiled, but it isn't warning free. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] 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
libexec/Makefile.inc breaks make release
Hi Kris, The commit to libexec/Makefile.inc to add WFORMAT?= 1 breaks releases because telnetd does not compile without warnings. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] === libexec/telnetd cc -nostdinc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DE NV_HACK -I/usr/src/libexec/telnetd/../../lib -DINET6 -I/usr/obj/usr/src/i386/ usr/include -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extr a-args -Werror -c /usr/src/libexec/telnetd/global.c cc -nostdinc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DE NV_HACK -I/usr/src/libexec/telnetd/../../lib -DINET6 -I/usr/obj/usr/src/i386/ usr/include -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extr a-args -Werror -c /usr/src/libexec/telnetd/slc.c cc -nostdinc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DE NV_HACK -I/usr/src/libexec/telnetd/../../lib -DINET6 -I/usr/obj/usr/src/i386/ usr/include -Werror -Wall -Wno-uninitialized -Wnon-const-format -Wno-format-extr a-args -Werror -c /usr/src/libexec/telnetd/state.c cc1: warnings being treated as errors /usr/src/libexec/telnetd/state.c: In function `send_do': /usr/src/libexec/telnetd/state.c:427: warning: non-constant format parameter /usr/src/libexec/telnetd/state.c: In function `send_dont': /usr/src/libexec/telnetd/state.c:612: warning: non-constant format parameter /usr/src/libexec/telnetd/state.c: In function `send_will': /usr/src/libexec/telnetd/state.c:749: warning: non-constant format parameter /usr/src/libexec/telnetd/state.c: In function `send_wont': /usr/src/libexec/telnetd/state.c:900: warning: non-constant format parameter *** Error code 1 Stop in /usr/src/libexec/telnetd. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /home/src/release. End Tue Feb 5 01:01:37 SAST 2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
