disk_clone() bug
I posted a bug report and patch in kern/29104 and Dima Dorfman also mentioned this in July/August, but it still has not been resolved. The method of triggering it that I detailed in my bug report no longer seems to work, but I've managed to create another one. # mdconfig -a -t swap -s 32m -u 10 # disklabel -r -w md10 auto # disklabel -e md10e (copy c to e and set type to 4.2BSD) # ls -l /dev/md10* crw-r- 1 root operator 95, 0x00010052 Oct 19 01:50 /dev/md10 crw-r- 1 root operator 95, 82 Oct 19 02:00 /dev/md10c crw-r- 1 root operator 95, 84 Oct 19 01:55 /dev/md10ec crw--- 1 root wheel 95, 0x00ff Oct 19 01:50 /dev/mdctl Now if you access (open(2)) md10e the system will kill itself when you run mdconfig -d. If I am doing something evil I'd like to know, but either way the kernel should not enter an endless loop! I have not had time to determine why disklabel -e md10e will kill it, but disklabel -e /dev/md10e will not. I think it has to do with how disklabel appends the 'c'. The patch that I provided in 29104 is probably not the correct solution (I like Dima's default better), and may not even be "fixing" the problem in the correct place. Any advice would be very welcome. -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fix for pam_nologin.so runtime error
> Forgot to mention, I had to make kcheckpass setuid root to make kcheckpass > itself work (just verified this on -stable). Yes - this is documented. :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SEXWEB NO.1 .. MEGAWEB-SEX !
Dear Ladies & Gentlemen, Welcome to the GREATEST SEX SHOW on the ENTIRE NET ! We now offer you to ENTER the World´s No.1 voted SEX-SERVER on the WEB ! By far the largest and most incredible content of LIVE SEX is now served to users WORLDWIDE! EVERYTHING is offered 100% ANONOMOUSLY & you don´t need to sign-up or have a creditcard ... The way it should be ! TO PLUGIN and get access to something you with guarantee NEVER have seen before, use ANY of the servers listed below ! Enjoy the BEST! Yours truly, HOTBABES GROUP To get EASY ACCESS & PLUGIN to the LARGEST CONTENT SEXSERVER on the NET, use any of the 2 SERVERS listed here: 1. http://wownet.onweb.cx 2. http://wwwap.to/wownet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disk_clone() bug
Sounds like the bug is the md driver cloning "md10ec" which it shouldn't do. This bug must naturally be in md_clone(), but I don't have the minutes right now to hunt it down. Should be quite simple to nail, it's just some string handling code. Poul-Henning In message <[EMAIL PROTECTED]>, Chad David writes: >I posted a bug report and patch in kern/29104 and Dima Dorfman also mentioned >this in July/August, but it still has not been resolved. The method of >triggering it that I detailed in my bug report no longer seems to work, >but I've managed to create another one. > ># mdconfig -a -t swap -s 32m -u 10 ># disklabel -r -w md10 auto ># disklabel -e md10e (copy c to e and set type to 4.2BSD) ># ls -l /dev/md10* >crw-r- 1 root operator 95, 0x00010052 Oct 19 01:50 /dev/md10 >crw-r- 1 root operator 95, 82 Oct 19 02:00 /dev/md10c >crw-r- 1 root operator 95, 84 Oct 19 01:55 /dev/md10ec >crw--- 1 root wheel 95, 0x00ff Oct 19 01:50 /dev/mdctl > >Now if you access (open(2)) md10e the system will kill itself when you >run mdconfig -d. If I am doing something evil I'd like to know, but either >way the kernel should not enter an endless loop! > >I have not had time to determine why disklabel -e md10e will kill it, but >disklabel -e /dev/md10e will not. I think it has to do with how disklabel >appends the 'c'. > >The patch that I provided in 29104 is probably not the correct solution >(I like Dima's default better), and may not even be "fixing" the problem >in the correct place. Any advice would be very welcome. > >-- >Chad David[EMAIL PROTECTED] >ACNS Inc. Calgary, Alberta Canada > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: disk_clone() bug
On 19-Oct-01 Chad David wrote: > I posted a bug report and patch in kern/29104 and Dima Dorfman also mentioned > this in July/August, but it still has not been resolved. The method of > triggering it that I detailed in my bug report no longer seems to work, > but I've managed to create another one. > ># mdconfig -a -t swap -s 32m -u 10 ># disklabel -r -w md10 auto ># disklabel -e md10e (copy c to e and set type to 4.2BSD) ># ls -l /dev/md10* > crw-r- 1 root operator 95, 0x00010052 Oct 19 01:50 /dev/md10 > crw-r- 1 root operator 95, 82 Oct 19 02:00 /dev/md10c > crw-r- 1 root operator 95, 84 Oct 19 01:55 /dev/md10ec > crw--- 1 root wheel 95, 0x00ff Oct 19 01:50 /dev/mdctl Well, you are supposed to be running disklabel -e on md10, not md10e. You edit the disklabel on a disk or slice, not the disklabel from inside of a partition defined by that disklabel. Make sense? :) Disklabel should probably fail to actually run in this case since md10e doesn't exist and certainly wouldn't have a valid disklabel to edit if it did exist. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disk_clone() bug
On Fri, Oct 19, 2001 at 08:24:57AM -0700, John Baldwin wrote: > > On 19-Oct-01 Chad David wrote: > > I posted a bug report and patch in kern/29104 and Dima Dorfman also mentioned > > this in July/August, but it still has not been resolved. The method of > > triggering it that I detailed in my bug report no longer seems to work, > > but I've managed to create another one. > > > ># mdconfig -a -t swap -s 32m -u 10 > ># disklabel -r -w md10 auto > ># disklabel -e md10e (copy c to e and set type to 4.2BSD) > ># ls -l /dev/md10* > > crw-r- 1 root operator 95, 0x00010052 Oct 19 01:50 /dev/md10 > > crw-r- 1 root operator 95, 82 Oct 19 02:00 /dev/md10c > > crw-r- 1 root operator 95, 84 Oct 19 01:55 /dev/md10ec > > crw--- 1 root wheel 95, 0x00ff Oct 19 01:50 /dev/mdctl > > Well, you are supposed to be running disklabel -e on md10, not md10e. You edit > the disklabel on a disk or slice, not the disklabel from inside of a partition > defined by that disklabel. Make sense? :) Disklabel should probably fail to > actually run in this case since md10e doesn't exist and certainly wouldn't have > a valid disklabel to edit if it did exist. Yes, that does make sense. Thank you. In normal cases disklabel would have failed, but the (md) disk clone code seems to (incorrectly) create it on the fly. Even an ls /dev/md10e would create the file. The problem is that ls -l md10eeec returns crw-r- 1 root operator 95, 20 Oct 19 02:19 /dev/md2eeec which I'm guessing is a bad device name :). Since phk has indicated where the real problem is I will see if I can track it down and provide a patch. Thanks. -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada "When Linux was first ported to the Furby platform, it suffered from significant stability and performance problems, which gave the Furby an unfortunate reputation as being unsuitable for enterprise-level computing." -- furbeowulf site To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal on Alpha
Fresh -current kernel on an DS10 Alpha box: System shutdown time has arrived Writing entropy file:. lock order reversal 1st 0xfc7574b0 clk @ ../../../alpha/alpha/clock.c:702 2nd 0xfc7526b0 callout @ ../../../kern/kern_timeout.c:225 witness_lock Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> db> db> panic panic: from debugger panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> trace Debugger() at Debugger+0x34 panic() at panic+0x100 db_panic() at db_panic+0x1c db_command() at db_command+0x2d4 db_command_loop() at db_command_loop+0xa4 db_trap() at db_trap+0x10c kdb_trap() at kdb_trap+0xe0 trap() at trap+0x21c XentIF() at XentIF+0x2c --- instruction fault (from ipl 6) --- Debugger() at Debugger+0x34 witness_lock() at witness_lock+0x80c _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x118 timeout() at timeout+0x44 sysbeep() at sysbeep+0x180 sc_bell() at sc_bell+0xb8 sc_switch_scr() at sc_switch_scr+0x374 scgetc() at scgetc+0x894 sckbdevent() at sckbdevent+0x2b8 atkbd_intr() at atkbd_intr+0x40 atkbd_isa_intr() at atkbd_isa_intr+0x30 isa_handle_intr() at isa_handle_intr+0x20 ithread_loop() at ithread_loop+0x1e8 fork_exit() at fork_exit+0x90 exception_return() at exception_return --- root of call graph --- db> Unfortunate side effect: it switches on its (loud) speaker beep while in de debugger :-/ W/ -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disk_clone() bug
On Fri, Oct 19, 2001 at 05:00:16PM +0200, Poul-Henning Kamp wrote:
>
> Sounds like the bug is the md driver cloning "md10ec" which it shouldn't
> do. This bug must naturally be in md_clone(), but I don't have the
> minutes right now to hunt it down.
>
> Should be quite simple to nail, it's just some string handling code.
I might be missing something again, so please be kind :).
First, there is not such function md_clone(), so I assume you mean
disk_clone()?
My analysis of this is that devfs_lookupx() attempts to have the driver
create any files that it does not have nodes for:
EVENTHANDLER_INVOKE(dev_clone, pname, strlen(pname), &cdev);
on line 339 of devfs_vnops.c.
The invoke will eventually end up calling disk_clone() which will attempt
to create the device, and then devfs_lookupx() will happily make the file
visable.
The code in disk_clone() looks for a device name that matches the start of
the name we are looking up, and if it finds it tries to make sure the
remander of the name matches the proper disk device naming convention.
If it does end up matching then it creates the minor device with the name
given. The problem is that it does not verify that the given name does not
contain any characters after the partition. So instead of seeing md10ec it
only sees md10e, and passes it on to make_dev(). The real issue is that the
minor number for md10ec and md10e are the same, so of course make_dev() is
unhappy when makedev() returns an named dev_t.
My original patch silently cut off the last part of the file name, which is
probably not correct. IMHO the code should fail first, ask questions later.
Dima's patch from around the end of July handles it properly I believe.
Something like this:
@@ -82,6 +82,11 @@
continue;
else
p = name[i] - 'a';
+
+ if (name[i + 1] != '\0') {
+ printf("WARNING: bad device name (\"%s\")\n", name);
+ return;
+ }
}
*dev = make_dev(pdev->si_devsw, dkmakeminor(u, s, p),
Note that this has nothing to do with md. Any device that is cloned by
disk_clone() will do the same thing. Just doing an ls -l ad2eeec followed
by ls -l ad2e will print the same "Driver mistake" message.
--
Chad David[EMAIL PROTECTED]
ACNS Inc. Calgary, Alberta Canada
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: > > Mike Smith wrote: > > > This just isn't going to work. The _CRS data stream stops at byte 0x17, > > and these extra items are simply mis-aimed. > > > > The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie. > > this is a BIOS bug, and should be reported to the vendor. (It should > > also have failed the Microsoft ACPI validation suite...) > > > > The correct action should probably be to silently discard the write > > operations outside of a defined buffer, and return Zeroes or Ones for a > > read outside a buffer. > > Do you have a patch to test this approach? While I understand that the best way to > resolve the problem is to convince vendors to fix their ACPI implementations, but > obviously this isn't going to happen any time soon, so appropriate workarround is > really a must. The problem is still here as of today's kernel. Please do something about it. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vmware on current: Could not get addres for /dev/vmnet1
This is -current from yesterday, with the recent patches to ansi.h to
get it to compile, and vmware2 with kse patches build today.
I did a
rm /compat/linux/dev/vmnet1;ln -s /dev/vmnet1 /compat/linux/dev
(see kse-patches announcement) and this seems to be working.
I tried bridged (using host-only conf. under vmware) and host-only
configuration.
The error
Could not get address for /dev/vmnet1: argument is invalid
Failed to configure ethernet0
is all I get... (this is the host-only case, for bridged it says
something like could not get bridgin status of /dev/vmnet1...)
ifconfig / ping for host-only configuration:
mp# ifconfig vmnet1
vmnet1: flags=8843 mtu 1500
inet 192.168.254.1 netmask 0xff00 broadcast 192.168.254.255
inet6 fe80::2bd:ccff:fe07:1%vmnet1 prefixlen 64 scopeid 0x5
ether 00:bd:cc:07:00:01
mp# ping 192.168.254.1
PING 192.168.254.1 (192.168.254.1): 56 data bytes
64 bytes from 192.168.254.1: icmp_seq=0 ttl=64 time=0.100 ms
64 bytes from 192.168.254.1: icmp_seq=1 ttl=64 time=0.070 ms
In the logs for host-only:
Oct 19 10:22:28 mp /boot/kernel/kernel: /dev/vmmon: Vmx86_DestroyVM: unlocked pages:
0, unlocked dirty pages: 0
Oct 19 10:26:04 mp /boot/kernel/kernel: /dev/vmmon: Vmx86_DestroyVM: unlocked pages:
0, unlocked dirty pages: 0
with bridged I get:
Oct 19 09:38:41 mp /boot/kernel/kernel: /dev/vmmon: Vmx86_DestroyVM: unlocked pages:
0, unlocked dirty pages: 0
Oct 19 09:39:40 mp /boot/kernel/kernel: linux: 'ioctl' fd=13, cmd=0x8940 ('\x89',64)
not implemented
Oct 19 09:39:44 mp /boot/kernel/kernel: /dev/vmmon: Vmx86_DestroyVM: unlocked pages:
0, unlocked dirty pages: 0
Any ideas?
Cheers, mathias
--
virtual earth
Mathias Picker
Geschäftsführer Gesellschaft für Wissens re/prä sentation mbH
[EMAIL PROTECTED]
Fon +49 89 / 540 7425-1
Fax +49 89 / 540 7425-9
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-emulation" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: arp: is using my IP address 0.0.0.0! ??!?!?
On Thu, 18 Oct 2001, Terry Lambert wrote:
TL>To expand a little...
TL>
TL>> That said, it's probably a good idea to never ARP for 0.0.0.0,
TL>> since a "who has" in that case is a really dumb idea, since,
TL>> as weas pointed out, it's intended to mean "this host", in the
TL>> absence of an IP address (i.e. 0.0.0.0 is not an IP address,
TL>> it's a special value meaning "not an IP address").
TL>
TL>It's probably also a good idea to make interfaces who have an
TL>IP of 0.0.0.0 _not_ respond to ARP requests for that address,
TL>and, just in case there are other idiots, we should also not
TL>give proxy ARP responses for that address, etiher.
I have run tcpdump all night to find out what happens. The host receives
an ARP request with a source address of 0.0.0.0:
18:33:51.222688 arp who-has hydra tell 0.0.0.0
0001 0800 0604 0001 0030 65c6 a174
c1af 8755
I think, this may happen if the host does not yet know it's IP address
(DHCP maybe?).
But FreeBSD-current for some unknown reason answers to this request:
18:33:51.222835 arp reply 0.0.0.0 is-at 0:60:97:a:99:f
0001 0800 0604 0002 0060 970a 990f
0030 65c6 a174
and then prints:
Oct 18 18:33:51 scotty /boot/kernel/kernel: arp: 00:30:65:c6:a1:74 is using my IP
address 0.0.0.0!
I think this is because I have an interface that is up and has NO IP
address:
lo0: flags=8049 mtu 16384
inet 127.0.0.1 netmask 0xff00
xl0: flags=8943 mtu 1500
inet 193.175.135.70 netmask 0xff00 broadcast 193.175.135.255
ether 00:60:97:0a:99:0f
media: Ethernet 10baseT/UTP (10baseT/UTP )
hatm0: flags=841 mtu 9180
media: ATM UTP/155MBit
status: active
lane0: flags=8802 mtu 1516
ether 00:00:00:00:00:00
I think it is definitly wrong to assume that an interface with no IP
address has IP address 0.0.0.0
harti
TL>Ghah. I hate special cases...
everything is a special case...
harti
TL>
TL>-- Terry
TL>
TL>To Unsubscribe: send mail to [EMAIL PROTECTED]
TL>with "unsubscribe freebsd-net" in the body of the message
TL>
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: arp: is using my IP address 0.0.0.0! ??!?!?
On Fri, Oct 19, 2001 at 11:12:48AM +0200, Harti Brandt wrote: > I have run tcpdump all night to find out what happens. The host receives > an ARP request with a source address of 0.0.0.0: > > 18:33:51.222688 arp who-has hydra tell 0.0.0.0 > 0001 0800 0604 0001 0030 65c6 a174 > c1af 8755 > > > I think, this may happen if the host does not yet know it's IP address > (DHCP maybe?). > > But FreeBSD-current for some unknown reason answers to this request: > > 18:33:51.222835 arp reply 0.0.0.0 is-at 0:60:97:a:99:f > 0001 0800 0604 0002 0060 970a 990f > 0030 65c6 a174 > > > and then prints: > > Oct 18 18:33:51 scotty /boot/kernel/kernel: arp: 00:30:65:c6:a1:74 is using my IP >address 0.0.0.0! Same here. My -CURRENT system is replying to those ARP request which carry 0.0.0.0 as sender IP address: 14:43:33.706099 arp who-has 158.227.48.193 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0 14:43:33.706152 arp reply 0.0.0.0 is-at 0:d0:b7:3e:a0:fb > I think this is because I have an interface that is up and has NO IP > address: I don't think so: # ifconfig -a fxp0: flags=8843 mtu 1500 inet 158.227.6.52 netmask 0xff00 broadcast 158.227.6.255 inet6 fe80::2d0:b7ff:fe3e:a0fb%fxp0 prefixlen 64 scopeid 0x1 inet6 fec0::9ee3:634 prefixlen 120 ether 00:d0:b7:3e:a0:fb media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff00 Something is broken in the ARP implementation of -CURRENT. --JMA -- ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: lock order reversal on Alpha
On 19-Oct-01 Wilko Bulte wrote: > Fresh -current kernel on an DS10 Alpha box: I have untested patches to fix this. Unfortunately they involve fixing the locking in teh clock code and I've only done i386 and alpha so far, but the same changes need to be replicated into all the otehr arch's. Alternatively, we should have MI devices for the RTC and i8254 timers so that this code wouldn't be duplicated all over the place. *sigh* If this is a UP box you should be able to just continue from this for now. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
probe & attach error
I'm trying to upgrade -current on one of our machines. This box is a Compaq Presario 900 Mhz Athlon. It errors on the NIC. I can't disable PnP in the bios, that feature doesn't exist in the compaq bios. I have tried several NIC's and pci slots with the same results. Also, I tried both "unset acpi_load" at boot and "hint.acpi.0.disable="1"" in /boot/device.hints. Neither made any difference. output from dmesg: ACPI debug layer 0x0 debug level 0x0 Copyright (c) 1992-2001 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.0-CURRENT #0: Wed Oct 17 21:33:28 AKDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/INTAKE Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 901599106 Hz CPU: AMD Athlon(tm) Processor (901.60-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc044<,AMIE,DSP,3DNow!> real memory = 402653184 (393216K bytes) avail memory = 385777664 (376736K bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xc04b8000. Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fa040 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_cpu0: on acpi0 acpi_cpu: CLK_VAL field overflows P_CNT register acpi_cpu: CLK_VAL field overlaps THT_EN bit acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 4.0 (no driver attached) xl0: <3Com 3cSOHO100-TX OfficeConnect> irq 5 at device 5.0 on pci0 xl0: couldn't map ports/memory device_probe_and_attach: xl0 attach returned 6 isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x1800-0x180f at device 20.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x14c0-0x14df irq 11 at device 20.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB Receiver, rev 1.10/9.10, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. ukbd0: Logitech USB Receiver, rev 1.10/10.20, addr 3, iclass 3/1 kbd0 at ukbd0 uhid0: Logitech USB Receiver, rev 1.10/10.20, addr 3, iclass 3/0 uhci1: port 0x14e0-0x14ff irq 11 at device 20.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhid1: American Power Conversion Back-UPS 350 FW: 5.1.D USB FW: c1, rev 1.10/1.00, addr 2, iclass 3/0 pci0: at device 20.4 (no driver attached) pcm0: port 0x1814-0x1817,0x1810-0x1813,0x1000-0x10ff irq 10 at device 20.5 on pci0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 ppc0 port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PRINTER HP ENHANCED PCL5,PJL plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xee08-0xee0b on acpi0 npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xc-0xc,0xe9000-0xebfff,0xec000-0xe on isa0 fdc1: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 ppc1: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio2: configured irq 3 not in bitmap of probed irqs 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ad0: 29311MB [59554/16/63] at ata0-master UDMA66 ad1: 38166MB [77545/16/63] at ata0-slave UDMA66 acd0: DVD-ROM at ata1-master PIO4 acd1: CD-RW at ata1-slave PIO4 Mounting root from ufs:/dev/ad1s1a Does anyone have any suggestions as to how to proceed from here? Beech -- Micro$oft: "Where can we make you go today?" --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: probe & attach error
> I'm trying to upgrade -current on one of our machines. This box is a Compaq > Presario 900 Mhz Athlon. It errors on the NIC. I can't disable PnP in the > bios, that feature doesn't exist in the compaq bios. I have tried several > NIC's and pci slots with the same results. > > Also, I tried both "unset acpi_load" at boot and "hint.acpi.0.disable="1"" > in /boot/device.hints. Neither made any difference. Of course it won't; ACPI has nothing to do with this. > xl0: <3Com 3cSOHO100-TX OfficeConnect> irq 5 at device 5.0 on pci0 > xl0: couldn't map ports/memory You're screwed. Sorry. We really need to do something about this. 8( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: arp: is using my IP address 0.0.0.0! ??!?!?
On Fri, Oct 19, 2001 at 04:58:21PM -0700, Mark Peek wrote:
> At 11:23 AM +0200 10/18/01, Harti Brandt wrote:
> >On Thu, 18 Oct 2001, Max Khon wrote:
> >
> >MK>hi, there!
> >MK>
> >MK>On Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote:
> >MK>
> >MK>> On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote:
> >MK>> > I've seen this when DHCP fails to allocate an address.
> >MK>> >
> >MK>>
> >MK>> But I am not using DHCP. Maybe there are other machines in the LAN (it is
> >MK>> a *big* LAN) trying to get their addresses using DHCP, and now -CURRENT
> >MK>> shows a message whenever detects one of those packets. I will try to
> >MK>> identify the senders (over 40!).
> >MK>>
> >MK>> Anyway, these "0.0.0.0" ARP messages are new in -CURRENT, and none of our
> >MK>> machines running FreeBSD 4.x show them.
> >MK>
> >MK>how current -CURRENT are you running?
> >
> >I have these two on a yesterday's current and remember that they appeared
> >after I saw a commit message approx. 2 weeks ago about adding hashing of
> >inet addresses (maybe rev. 1.83 of if_ether.c).
>
>
> Yes, it does appear to be due to this commit. The first address on the
> interface queue has an address of 0.0.0.0. Here's a patch that works for
> me to block the messages. I'm guessing at the correct behavior so use at
> your own risk. At least the voices^Wlog messages have stopped. :-)
Below is the patch that I've sent to the people who reported the
problem, I'm waiting to hear back from them that it works.
--
Jonathan
Index: if_ether.c
===
RCS file: /ncvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c 2001/10/17 18:07:05 1.85
+++ if_ether.c 2001/10/19 15:38:07
@@ -593,10 +593,12 @@
isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
+* No match, use the first inet address on the receive interface
* as a dummy address for the rest of the function.
*/
- ifa = TAILQ_FIRST(&ifp->if_addrhead);
+ TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link)
+ if (ifa->ifa_addr && ifa->ifa_addr->sa_family == AF_INET)
+ break;
if (ifa == NULL) {
m_freem(m);
return;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4 required?
On Thu, Oct 18, 2001 at 09:33:09PM +0200, Riccardo Torrini wrote: > Is a real need for ports under -CURRENT to require (from a > week or two, I don't remember) XFree86-libraries? Yes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: applix 5.0 and current
Warner Losh wrote: > Yup. I've done things like creating a chroot area and mounting a 3.5 > or 2.2.8 cdrom and then mounting another fs in that chroot area to > access the sources and then building it there. But as you go back in > time in FreeBSD it gets much harder to have ports be supported... I have a shell script which does this, given a DISC2 image tarball. It should probably be included on the DISC2 CDROM... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vmware on current: Could not get addres for /dev/vmnet1
On 19 Oct, Dag-Erling Smorgrav wrote: > [EMAIL PROTECTED] writes: >> The error >> >> Could not get address for /dev/vmnet1: argument is invalid >> Failed to configure ethernet0 >> >> is all I get... (this is the host-only case, for bridged it says >> something like could not get bridgin status of /dev/vmnet1...) > > Can you send me a ktrace? I suspect my linux_ioctl.c commits may be > at fault. Does anyone know where to get an eval license for vmware2, to run it as root? Has anyone seen similar problem on recent -current or has someone an idea why vmware is issuing a SIOCGIFCONF ioctl without providing an interface name? Oct 19 18:04:53 mp /boot/kernel/kernel: linux_ioctl_socket(): ioctl 35093 on Oct 19 18:04:55 mp /boot/kernel/kernel: /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 0, unlocked dirty pages: 0 -- virtual earth Mathias Picker Geschäftsführer Gesellschaft für Wissens re/prä sentation mbH [EMAIL PROTECTED] Fon +49 89 / 540 7425-1 Fax +49 89 / 540 7425-9 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
Le 2001-10-14, Paul van der Zwan écrivait : > I am using -current box as a homedir server for my Solaris clients and > have noticed a wierd problem. Other problems here, with Solaris 2.[68] as clients, and -CURRENT of yesterday as server. ls works, but ls -l issues a 'NFS getacl failed' message *and* waits for a timeout once for each file in the directory. The server is not multi-homed, and a packet capture shows no trace of address mismatch problems. One interesting thing is that the client first does GETATTR on the file (and apparently gets a reply), and then sends some other RPC, to which the server never replies. Could this be the getacl request mentioned in the client error message? I see no mention of getacl whatsoever in the -CURRENT server code. If no such function is implemented, shouldn't we reject the request? A packet capture is available at http://www.infres.enst.fr/~quinot/nfs.cap Client is 137.194.192.1, server is 137.194.162.11. The test consists in first performing an 'ls' on one file, then an 'ls -l' on the same file. Result: ls photos-ta; ls -l photos-ta photos-ta NFS getacl failed for server shalmaneser.enst.fr: error 5 (RPC: Timed out) -rw--- 1 quinot astre474 Oct 18 14:17 photos-ta Thomas. -- Thomas Quinot ** Département Informatique & Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vmware on current: Could not get addres for /dev/vmnet1
[EMAIL PROTECTED] writes: > Has anyone seen similar problem on recent -current or has someone an > idea why vmware is issuing a SIOCGIFCONF ioctl without providing an > interface name? > > Oct 19 18:04:53 mp /boot/kernel/kernel: linux_ioctl_socket(): ioctl 35093 on To clarify, this is from debugging output I added to linux_ioctl.c, and it's supposed to print an interface name after "on". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: arp: is using my IP address 0.0.0.0! ??!?!?
At 9:14 PM -0500 10/19/01, Jonathan Lemon wrote: >Below is the patch that I've sent to the people who reported the >problem, I'm waiting to hear back from them that it works. Thanks for the real patch. It appears to work fine on my system. No log messages and arps look good so far. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: arp: is using my IP address 0.0.0.0! ??!?!?
hi, there!
> Same here. My -CURRENT system is replying to those ARP request which carry
> 0.0.0.0 as sender IP address:
>
> 14:43:33.706099 arp who-has 158.227.48.193 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0
> 14:43:33.706152 arp reply 0.0.0.0 is-at 0:d0:b7:3e:a0:fb
>
> > I think this is because I have an interface that is up and has NO IP
> > address:
>
> I don't think so:
>
> # ifconfig -a
> fxp0: flags=8843 mtu 1500
> inet 158.227.6.52 netmask 0xff00 broadcast 158.227.6.255
> inet6 fe80::2d0:b7ff:fe3e:a0fb%fxp0 prefixlen 64 scopeid 0x1
> inet6 fec0::9ee3:634 prefixlen 120
> ether 00:d0:b7:3e:a0:fb
> media: Ethernet autoselect (100baseTX )
> status: active
> lo0: flags=8049 mtu 16384
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> inet 127.0.0.1 netmask 0xff00
>
> Something is broken in the ARP implementation of -CURRENT.
please try this patch (provided by jlemon)
Index: if_ether.c
===
RCS file: /ncvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c 2001/10/17 18:07:05 1.85
+++ if_ether.c 2001/10/19 15:38:07
@@ -593,10 +593,12 @@
isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
+* No match, use the first inet address on the receive interface
* as a dummy address for the rest of the function.
*/
- ifa = TAILQ_FIRST(&ifp->if_addrhead);
+ TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link)
+ if (ifa->ifa_addr && ifa->ifa_addr->sa_family == AF_INET)
+ break;
if (ifa == NULL) {
m_freem(m);
return;
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Erm, who broke nice?
I know that some people are complaining about the performance of current and all, but breaking nice so that we can't make processes run slower is just going too far. :) > nice -20 buildworld setpriority: Permission denied. Any ideas? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Erm, who broke nice?
On 19-Oct-01 John Baldwin wrote: > I know that some people are complaining about the performance of current and > all, but breaking nice so that we can't make processes run slower is just > going > too far. :) > >> nice -20 buildworld > setpriority: Permission denied. > > Any ideas? Idea #1: PEBKAC due to me using tcsh and it having an arguably more intuitive but nonetheless gratuitously incompatible builtin nice command. nice +20 buildworld worked fine. *sigh* -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: arp: is using my IP address 0.0.0.0! ??!?!?
At 11:23 AM +0200 10/18/01, Harti Brandt wrote:
>On Thu, 18 Oct 2001, Max Khon wrote:
>
>MK>hi, there!
>MK>
>MK>On Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote:
>MK>
>MK>> On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote:
>MK>> > I've seen this when DHCP fails to allocate an address.
>MK>> >
>MK>>
>MK>> But I am not using DHCP. Maybe there are other machines in the LAN (it is
>MK>> a *big* LAN) trying to get their addresses using DHCP, and now -CURRENT
>MK>> shows a message whenever detects one of those packets. I will try to
>MK>> identify the senders (over 40!).
>MK>>
>MK>> Anyway, these "0.0.0.0" ARP messages are new in -CURRENT, and none of our
>MK>> machines running FreeBSD 4.x show them.
>MK>
>MK>how current -CURRENT are you running?
>
>I have these two on a yesterday's current and remember that they appeared
>after I saw a commit message approx. 2 weeks ago about adding hashing of
>inet addresses (maybe rev. 1.83 of if_ether.c).
Yes, it does appear to be due to this commit. The first address on the
interface queue has an address of 0.0.0.0. Here's a patch that works for
me to block the messages. I'm guessing at the correct behavior so use at
your own risk. At least the voices^Wlog messages have stopped. :-)
Mark
--
Index: if_ether.c
===
RCS file: /cvs/freebsd/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c 2001/10/17 18:07:05 1.85
+++ if_ether.c 2001/10/19 23:53:44
@@ -593,15 +593,19 @@
isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
-* as a dummy address for the rest of the function.
+* No match, use the first non-0.0.0.0 address on the receive
+* interface as a dummy address for the rest of the function.
*/
- ifa = TAILQ_FIRST(&ifp->if_addrhead);
- if (ifa == NULL) {
- m_freem(m);
- return;
- }
- ia = ifatoia(ifa);
+ TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link)
+ if (ifatoia(ifa)->ia_addr.sin_addr.s_addr != 0) {
+ ia = ifatoia(ifa);
+ goto match;
+ }
+
+ /* No applicable interface/address so bail... */
+ m_freem(m);
+ return;
+
match:
myaddr = ia->ia_addr.sin_addr;
if (!bcmp(ar_sha(ah), IF_LLADDR(ifp), ifp->if_addrlen)) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
