Re: ** HEADS UP ** portmap daemon renamed to rpcbind
On Sunday, 25 March 2001 at 23:48:10 -0800, Doug Barton wrote: > Greg Lehey wrote: >> >> On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: >>> The Portmapper binary has been renamed from `portmap' to `rpcbind'. >> >> Why? > > So we can be more like sysV This is good? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
Greg Lehey wrote: > > On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > > The Portmapper binary has been renamed from `portmap' to `rpcbind'. > > Why? So we can be more like sysV -- Perhaps the greatest damage the American system of education has done to its children is to teach them that their opinions are relevant simply because they are their opinions. Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent interface/routing changes breaks on-demand PPP
On Sun, Mar 25, 2001 at 02:46:22AM +0100, Brian Somers wrote: > > > On Fri, Mar 23, 2001 at 23:11:56 +, Brian Somers wrote: > > > > 1. Ppp is in -auto mode (or a ``set mode auto'' has been done). > > > >Here, ppp configures the interface as soon as it sees the ``set > > > >ifaddr'' line and never undoes that configuration. An ``add'' > > > >with a fixed IP number would never have worked if it's before the > > > >``set ifaddr''. If it's after the ``set ifaddr'', nothing should > > > >ever remove it (as the interface will stay configured). > > > > > > > > 2. Ppp is not in -auto mode. Here, ppp won't assign the interface > > > >address 'till IPCP is up. Any attempt to ``add'' a route with a > > > >static IP number in ppp.conf should fail. > > > > > > > > So, the recent routing changes shouldn't have made a difference. > > > > > > > > Anyone know what I'm missing ? Andre, what does your ppp.conf look > > > > like and how are you running ppp ? > > > > > > ppp in -auto mode, "add" is after "set ifaddr" > > > > In which case your interface should stay configured despite the link > > coming down and your route should *not* be deleted. > > > > I'll see if I can reproduce this here (I need to upgrade a machine > > first). > > This was happening because ppp was deleting then re-adding the > interface address when IPCP came up, causing the new routing code to > nuke the static route. I've added an optimisation to stop this from > happening, so your configuration should work ok again with > src/usr.sbin/ppp/iface.c 1.17. > You mean, ppp(8) does not do this now if negotiated address does not change? -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: si_drv1 used already?
In message <[EMAIL PROTECTED]>, Julian Elischer writes: >Poul-Henning Kamp wrote: >> >> In message <[EMAIL PROTECTED]>, Julian Elischer writes: >> > >> >The vmware vmmon driver used to use si_drv1 but suddenly it appears to >> >have already been used (at least it is no-longer non-zero). >> >It would fail to open because it checks it before using it during open. >> >Changing the driver to use si_drv2 fixes the problem. >> > >> >Since drv1 is defined as 'for the use of the driver' >> >I am not sure that it is wrong for the driver to use it. >> >In fact many other drivers do use it without testing it. >> > >> >I see it's used in freedev() and make_dev_alias(). >> >Is it safe for the driver to use it even if it is non-zero? >> >> I think you need to give me a bit more details before I an answer >> meaningfully... >> >> Are you sure that the value is not from previous use by vmmon ? > >no I am not sure.. I will test further. >the sequence: >1/ failed to open >2/ unload module Make sure vmmon calles destroy_dev() on all dev_t's created with make_dev() or make_dev_alias() when unloaded. This process is not automatic, and I am not sure we can safely make it automatic. We may be able to make it easier though. -- 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: si_drv1 used already?
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Julian Elischer writes: > > > >The vmware vmmon driver used to use si_drv1 but suddenly it appears to > >have already been used (at least it is no-longer non-zero). > >It would fail to open because it checks it before using it during open. > >Changing the driver to use si_drv2 fixes the problem. > > > >Since drv1 is defined as 'for the use of the driver' > >I am not sure that it is wrong for the driver to use it. > >In fact many other drivers do use it without testing it. > > > >I see it's used in freedev() and make_dev_alias(). > >Is it safe for the driver to use it even if it is non-zero? > > I think you need to give me a bit more details before I an answer > meaningfully... > > Are you sure that the value is not from previous use by vmmon ? no I am not sure.. I will test further. the sequence: 1/ failed to open 2/ unload module 3/ load newly compiled module with printfs 4/ discover si_drv1 in use 5/ unload, load new version using si_drv2 6/ succeed. it is possible that the recompile fixed another problem that had caused another abort, but had left si_drv1 non-zero. I'll need to recompile and reboot to confirm. > > -- > 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. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: si_drv1 used already?
In message <[EMAIL PROTECTED]>, Julian Elischer writes: > >The vmware vmmon driver used to use si_drv1 but suddenly it appears to >have already been used (at least it is no-longer non-zero). >It would fail to open because it checks it before using it during open. >Changing the driver to use si_drv2 fixes the problem. > >Since drv1 is defined as 'for the use of the driver' >I am not sure that it is wrong for the driver to use it. >In fact many other drivers do use it without testing it. > >I see it's used in freedev() and make_dev_alias(). >Is it safe for the driver to use it even if it is non-zero? I think you need to give me a bit more details before I an answer meaningfully... Are you sure that the value is not from previous use by vmmon ? -- 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
si_drv1 used already?
The vmware vmmon driver used to use si_drv1 but suddenly it appears to have already been used (at least it is no-longer non-zero). It would fail to open because it checks it before using it during open. Changing the driver to use si_drv2 fixes the problem. Since drv1 is defined as 'for the use of the driver' I am not sure that it is wrong for the driver to use it. In fact many other drivers do use it without testing it. I see it's used in freedev() and make_dev_alias(). Is it safe for the driver to use it even if it is non-zero? -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
use md device in /etc/rc.diskless{1,2}
Hi. I have diskless-PC which was used /boot/pxeboot. But latest FreeBSD-current is output below messages and some fsck_nfs problem. WARNING: MFS is being phased out in preference for md devices WARNING: Please see mdconfig(8) for details WARNING: Continuing in 15 seconds Does someone already rewrite and use mdconfig in /etc/rc.diskless1 and diskless2? Cheers. --- MIHIRA, Sanpei Yoshiro Yokohama, Japan. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
I get a slightly different backtrace, but was able to use my palm pilot as the
serial console. I have had this same problem for quit a while (about a month).
I suspect a locking issue related to Seigo Tanimura's commit on Feb 25. My last
cvsup was within the past 24 hours and the kernel was built in a clean
directory.
I can try to get more information if necessary.
Jim Bloom
[EMAIL PROTECTED]
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1a0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c8006
stack pointer = 0x10:0xc04e66dc
frame pointer = 0x10:0xc04e66db>
trace
_mtx_lock_sleep(c0ecda08,0,c036d471,268) at _mtx_lock_sleep+0x29a
mpu_uartmode(c0ecda00) at mpu_uartmode+0x63
mpu_attach(c0ebd100,c0ebd100,c0ebd100,c0e67080,c04e675c) at mpu_attach+0x25
mpusbc_attach(c0ebd100,c0ebd100,c0ea5ac0,c036e926,1) at mpusbc_attach+0x19
device_probe_and_attach(c0ebd100) at device_probe_and_attach+0x9a
bus_generic_attach(c0ea2000,c0ebd080,c0ea5ac0,c0ea2000,c036e935) at
bus_generic_attach+0x16
sbc_attach(c0ea2000,c0eadb00,c0ea2000,7,0) at sbc_attach+0x3cc
device_probe_and_attach(c0ea2000,c0404c4c,c03f9030,4eb000,c0eadb00) at
device_probe_and_attach+0x9a
isa_probe_children(c0ea2980,c04e6ff8,c01b1f74,0,4e4c00) at
isa_probe_children+0x143
configure(0,4e4c00,4e4000,0,c01277d2) at configure+0x39
mi_startup() at mi_startup+0x68
begin() at begin+0x29
db> panic
panic: from debugger
Debugger("panic")
Stopped at _mtx_lock_sleep+0x29a: movl0x1a0(%edx),%eax
Szilveszter Adam wrote:
>
> Hello folks,
>
> I have tried it with today's -CURRENT, and as soon as I try to boot a
> kernel with the options (this has occured also earlier but wanted to make
> sure that I try today's sources first)
>
> device midi
> device seq
>
> (my sound card is a ISAPnP SB 64 AWE)
>
> I use device sbc too.
>
> the kernel still panics with Fatal Trap 12. I have Seigo Tanimura's
> fixes, and yet this still happens. I do not have a serial console, so here
> a short trace output transcribed:
>
> _mtx_lock_sleep
> mpu_uartmode
> mpu_attach
> mprobe_attach
> device_probe_and_attach
> bus_generic_attach
> sbc_attach
> device_probe_and_attach
> isa_probe_children
> configure
> mi_startup()
> begin()
>
> At the point of panic not even the swap partition is available yet so the
> machine does not dump. How can I force it?
>
> I would like to offer any and all help to anyone wanting to debug this; I
> can reproduce the problem at will and luckily no FS corruption occurs
> because the panic is so early on boot.:-)
>
> Of course, as soon as I omit the midi part, the kernel boots fine, and the
> sound card works too.
> --
> Regards:
>
> Szilveszter ADAM
> Szeged University
> Szeged Hungary
>
> 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
No Subject
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
* Greg Lehey <[EMAIL PROTECTED]> [010325 15:33] wrote: > On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > > The Portmapper binary has been renamed from `portmap' to `rpcbind'. > > Why? We've upgraded to Sun's TIRPC code, this includes rpcbind as a replacement for portmapper. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: > The Portmapper binary has been renamed from `portmap' to `rpcbind'. Why? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newcard/cardbus instabilities
In message <[EMAIL PROTECTED]> "Johny Mattsson (EPA)" writes: : I also removed the "device pccard" config option, and as a result : lost support for the modem card, but in return this fixed the : watchdog timeouts, and the lan card works quite well now. : I guess I'll have to keep a backup kernel with the old pcic compiled : in if I want to use the modem... for now I'm very happy to have a : working lan card! Ah. You aren't supposed to compile in both oldcard and newcard at the same time... Wanrer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newcard/cardbus instabilities
In message <[EMAIL PROTECTED]> Mike Smith writes: : This looks OK, though you might want to disable the pccard support, since : it's known to be broken right now. pccard support is not broken right now. If there's a "known" issue, I sure don't know about it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newcard/cardbus instabilities
In message <[EMAIL PROTECTED]> "Johny Mattsson (EPA)" writes: : The xl driver spits out numerous "xl0: watchdog timeout", and I get pings : around the one second mark, even to machines on the same switch. Trying to : maintain TCP sessions without keeping a running ping in the background is : futile, due to the packet loss. : : So basically, I'm wondering what I can do to help getting this : fixed? It looks like the IRQ isn't beeing assigned properly. You'll have to help us figure out why. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
"David O'Brien" wrote:
> On Sun, Mar 25, 2001 at 04:08:47PM +0300, Valentin Nechayev wrote:
> > 192.168.5 should be interpreted as 192.168.0.5 in host address context,
> > but as 192.168.5.0 in network address context. (Such network address
> > context is well seen in sentences such as "10/8", "192.168/16".)
>
> Where is this documented?
peter@daintree[10:39am]/tmp-162> cat foo.c
main()
{
int x;
x = inet_network("127.1");
printf("inet_network(127.1) = %x\n", x);
x = inet_addr("127.1");
printf("inet_addr(127.1) = %x\n", htonl(x));
}
peter@daintree[10:39am]/tmp-163> cc -o foo foo.c
peter@daintree[10:40am]/tmp-164> ./foo
inet_network(127.1) = 7f01
inet_addr(127.1) = 7f01
inet_addr() and family returns network order, while inet_network() returns
host order.
The old mountd code went to a lot of trouble to keep the two seperate.
In host context, it would have interpreted it as 192.168.0.5, but in network
/ netmask context it intentionally interpreted it as 192.168.5.0/mask.
See the old get_host() vs get_net() code.
Now that I have looked more closely, IMHO the new code is broken. :-(
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vm page panic
: Hi guys, : : ok, sources cvsupped yesterday afternoon, just before my ffs_alloc.c : commit [which I did, obviously, add myself locally]. : : Box had been running for a while when all of a sudden it got into a : panic: : : vm_page_alloc: free/cache page 0xc0776fa4 was dirty : : a trace in ddb shows: : : allocbuf() : getblk() : ffs_balloc() : ffs_write() : vn_rdwr() : elf_coredump() : coredump() This particular panic will have a delayed effect, so the trace probably isn't the problem. Something occured some period of time prior that caused a (probably cache) page to be marked dirty. Then later when vm_page_alloc() tries to reuse the page it notices that it's dirty when it shouldn't be. I have not seen this panic literaly for years - there was a bug in John Dyson's original code that could cause it but it was fixed a very long time ago. So I'm guessing that the panic is a side effect of a newly introduced bug somewhere in current. Possibly a race of some sort with the mutex/threading/interrupt code, but I don't know. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
On Sun, Mar 25, 2001 at 04:08:47PM +0300, Valentin Nechayev wrote: > 192.168.5 should be interpreted as 192.168.0.5 in host address context, > but as 192.168.5.0 in network address context. (Such network address > context is well seen in sentences such as "10/8", "192.168/16".) Where is this documented? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hangs with latest sources
> Included patch should fix this problem. It does, indeed. Thanks! Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hangs with latest sources
On Sun, 25 Mar 2001, Blaz Zupan wrote:
> My kernel compiled from -current sources as of today morning hangs after
> recognizing the sound hardware, the last line display is:
>
> pcm0: at port
> 0x240-0x24f,0xe80-0xe87,0x388-0x38f,0x300-0x301,0x100-0x101 irq 7 drq
> 0,1 on isa0
Included patch should fix this problem.
greid
Index: mss.c
===
RCS file: /usr/home/ncvs/src/sys/dev/sound/isa/mss.c,v
retrieving revision 1.65
diff -u -r1.65 mss.c
--- mss.c 2001/03/24 23:10:25 1.65
+++ mss.c 2001/03/25 17:55:10
@@ -174,13 +174,13 @@
static void
mss_lock(struct mss_info *mss)
{
- snd_mtxlock(mss);
+ snd_mtxlock(mss->lock);
}
static void
mss_unlock(struct mss_info *mss)
{
- snd_mtxunlock(mss);
+ snd_mtxunlock(mss->lock);
}
static int
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
> 192.168.5 should be interpreted as 192.168.0.5 in host address context, > but as 192.168.5.0 in network address context. (Such network address > context is well seen in sentences such as "10/8", "192.168/16".) The only problem I see with 10/8 is that when broken down into binary they do not match 10.0.0.0/8 1010 and just 10 1010 the significance of one "octet" is that the above(10.0.0.0) can be written in this form as 167772160 which doesn't equal 10 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
Bikeshed time ! :-) - Original Message - From: "Valentin Nechayev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, March 25, 2001 3:08 PM Subject: Re: /etc/exports: 192.168.5 = 192.168.0.5 > > > /var -alldirs -maproot=root: -network 192.168.5 -mask 255.255.255.0 > > > showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 > > This is the correct interpretation. > > > Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 > > > used to work. > > It was broken, then. :-) > > 192.168.5 should be interpreted as 192.168.0.5 in host address context, > but as 192.168.5.0 in network address context. (Such network address > context is well seen in sentences such as "10/8", "192.168/16".) > > netch@iv:~/tmp>netstat -rn | grep 192 > 192/8 127.0.0.1 UGSc00 lo0 > > In case in question, when -network prefix is occured, parsing should > be performed with network address context, not host address context. > > > /netch > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
Hello folks, I have tried it with today's -CURRENT, and as soon as I try to boot a kernel with the options (this has occured also earlier but wanted to make sure that I try today's sources first) device midi device seq (my sound card is a ISAPnP SB 64 AWE) I use device sbc too. the kernel still panics with Fatal Trap 12. I have Seigo Tanimura's fixes, and yet this still happens. I do not have a serial console, so here a short trace output transcribed: _mtx_lock_sleep mpu_uartmode mpu_attach mprobe_attach device_probe_and_attach bus_generic_attach sbc_attach device_probe_and_attach isa_probe_children configure mi_startup() begin() At the point of panic not even the swap partition is available yet so the machine does not dump. How can I force it? I would like to offer any and all help to anyone wanting to debug this; I can reproduce the problem at will and luckily no FS corruption occurs because the panic is so early on boot.:-) Of course, as soon as I omit the midi part, the kernel boots fine, and the sound card works too. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
Its always been working in the correct way for stable and currently is right now. - Original Message - From: "Daniel C. Sobral" <[EMAIL PROTECTED]> To: "Leif Neland" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, March 25, 2001 6:52 AM Subject: Re: /etc/exports: 192.168.5 = 192.168.0.5 > Leif Neland wrote: > > > > > > showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 > > > > > > This is the correct interpretation. > > > > > > > > > > > Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 > > > > used to work. > > > > > > It was broken, then. :-) > > > > > So an unlisted bug was fixed :-) > > Quick! Open a PR about -stable! :-) > > -- > Daniel C. Sobral (8-DCS) > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > all your kernels arpanic: blockable sleep lock (sleep mutex) Giant @ > ../../kern/kern_sig.c:153 > > 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
No Subject
i cd rom is locked what can I do instead trying cd until unlocked is there any command to do ?
Re: vm page panic
Date: Sun, 25 Mar 2001 11:20:17 +0200 From: Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]> To: Kirk McKusick <[EMAIL PROTECTED]>, Peter Wemm <[EMAIL PROTECTED]>, Paul Saab <[EMAIL PROTECTED]>, Matt Dillon <[EMAIL PROTECTED]>, Soeren Schmidt <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: vm page panic Hi guys, ok, sources cvsupped yesterday afternoon, just before my ffs_alloc.c commit [which I did, obviously, add myself locally]. Box had been running for a while when all of a sudden it got into a panic: vm_page_alloc: free/cache page 0xc0776fa4 was dirty a trace in ddb shows: allocbuf() getblk() ffs_balloc() ffs_write() vn_rdwr() elf_coredump() coredump() Unfortunately my ata controller didn't get reprobed [just was hanging there] so I couldn't get a crashdump. =( [HPT366] So consider this a heads-up, since you might encounter this. Extra info: devfs running, / is normal FFS /tmp, /var, /usr, /storage all soft-updated. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Pleasure's a sin, and sometimes sin's a pleasure... The latest round of changes to ffs_alloc.c add code which is only ever used by background fsck which is not yetbeing used. So, it seems very unlikely that your panic has been triggered byv these changes. Kirk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hangs with latest sources
My kernel compiled from -current sources as of today morning hangs after recognizing the sound hardware, the last line display is: pcm0: at port 0x240-0x24f,0xe80-0xe87,0x388-0x38f,0x300-0x301,0x100-0x101 irq 7 drq 0,1 on isa0 Ctrl-Alt-Esc does not work. I'll be compiling a kernel with the latest sources but without the latest sound driver update later today to verify if the sound driver is indeed causing the trouble. Kernel config file and dmesg from a working kernel is included below. machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GOLD maxusers32 makeoptions DEBUG=-g options INET options IPSEC options IPSEC_ESP options FFS options SOFTUPDATES options DEVFS options NFS options MSDOSFS options CD9660 options PROCFS options COMPAT_43 options SCSI_DELAY=5000 options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options COMPAT_LINUX options DDB options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options INCLUDE_CONFIG_FILE device isa device pci device fdc device ata device atadisk device atapicd device atkbdc 1 device atkbd options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP="si.iso" device psm device vga device splash options SC_DFLT_FONT makeoptions SC_DFLT_FONT=iso02 device sc 1 device npx device apm device pcm device sio device miibus device xl device card device pcic #device pccard #device cardbus #device pcic #device pccbb device wi device loop device ether device tun device pty device bpf device md device random options ELSA_QS1ISA device isic device "i4bq921" device "i4bq931" device "i4b" device "i4btrc"4 device "i4bctl" device "i4brbch" 4 device "i4btel"2 device "i4bisppp" 4 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 #3: Tue Mar 20 19:16:42 CET 2001 [EMAIL PROTECTED]:/home/blaz/FreeBSD/src/sys/compile/GOLD Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (232.88-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 67108864 (65536K bytes) avail memory = 61153280 (59720K bytes) Preloaded elf kernel "kernel" at 0xc0414000. Intel Pentium detected, installing workaround for F00F bug Using $PIR table, 6 entries at 0xc00fdf60 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcf0-0xfcff at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 (no driver attached) pci0: at 7.3 (no driver attached) pci0: at 13.0 (no driver attached) xl0: <3Com 3c900-TPO Etherlink XL> irq 7 at device 14.0 on pci0 xl0: failed to enable I/O ports! device_probe_and_attach: xl0 attach returned 6 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pcic0: at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 isic0: at port 0x160-0x167 irq 5 on isa0 isic0: passive stack unit 0 pcm0: at port 0x240-0x24f,0xe80-0xe87,0x388-0x38f,0x300-0x301,0x100-0x101 irq 7 drq 0,1 on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources i4bctl: ISDN system control port attached i4btrc: 4 ISDN trace device(s) attached i4bisppp: 4 ISDN SyncPPP device(s) attached (VJ header compression) i4b: ISDN call control device attached IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to accept, logging dis
Re: /etc/exports: 192.168.5 = 192.168.0.5
> > /var -alldirs -maproot=root: -network 192.168.5 -mask 255.255.255.0 > > showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 > This is the correct interpretation. > > Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 > > used to work. > It was broken, then. :-) 192.168.5 should be interpreted as 192.168.0.5 in host address context, but as 192.168.5.0 in network address context. (Such network address context is well seen in sentences such as "10/8", "192.168/16".) netch@iv:~/tmp>netstat -rn | grep 192 192/8 127.0.0.1 UGSc00 lo0 In case in question, when -network prefix is occured, parsing should be performed with network address context, not host address context. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
Leif Neland wrote: > > > > showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 > > > > This is the correct interpretation. > > > > > > > > Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 > > > used to work. > > > > It was broken, then. :-) > > > So an unlisted bug was fixed :-) Quick! Open a PR about -stable! :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] all your kernels arpanic: blockable sleep lock (sleep mutex) Giant @ ../../kern/kern_sig.c:153 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
> > showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 > > This is the correct interpretation. > > > > > Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 > > used to work. > > It was broken, then. :-) > So an unlisted bug was fixed :-) Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world stops during i4b compilation
On Sunday 25 March 2001 13:53, Marc van Woerkom wrote: > > i4b is an ethernet interface, how do you think PPP/HDLC works ? The > > interface is registered with the networking stack, just like a "real" > > networking card is. This make the ether device mandatory. > > Hi Gary! > > I simply lack knowledge of how network devices are organized. > > It might have been possible that network devices exist, that > don't belong to that class of ethernet interfaces. > > I believed that i4b might be such a device, as I can't remember > pulling in "ether" in my older kernel configs. > well, it seems that I'm wrong. Hellmuth Michaelis tells me that it _should_ be possible to use i4b without ether. Looks like this is a bug. -- Gary Jennejohn [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world stops during i4b compilation
> i4b is an ethernet interface, how do you think PPP/HDLC works ? The > interface is registered with the networking stack, just like a "real" > networking card is. This make the ether device mandatory. Hi Gary! I simply lack knowledge of how network devices are organized. It might have been possible that network devices exist, that don't belong to that class of ethernet interfaces. I believed that i4b might be such a device, as I can't remember pulling in "ether" in my older kernel configs. Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world stops during i4b compilation
On Sunday 25 March 2001 00:11, Marc van Woerkom wrote: > > >Ok, I did an ediff against NOTES. Perhaps it was the "1" argument to > > > > > >device loop1 #Network loopback device > > > > > >that was missing. I'll try again. > > > > Hmmm Seems odd. If you get a recurrence, you might want to share a > > diff between GENERIC and what you're using. > > Now it compiles. > > I had to put in a "device ether" line into my config to compile > a kernel with i4b (IDSN) drivers. > > And this on box without ethernet card. > > Is this a bug or a feature? i4b is an ethernet interface, how do you think PPP/HDLC works ? The interface is registered with the networking stack, just like a "real" networking card is. This make the ether device mandatory. -- Gary Jennejohn [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ICH2-M IDE controller
It seems Benjamin Close wrote: > Hi All, > Is anyone looking at supporting the Intel ICH2-M IDE controller? Yes. > This controller is basically the same as the ICH2 controller except it has > extra powermanagment features as it's the for portable computers (hence > the M=mobile). I'm currently using the attached patch which runs > flawlessly on my laptop. However, I'm just an amature code hacker and > hence can't guarentee I haven't missed something between the chipsets. This patch seems about right, I have something very semilar in one of my trees here, just I havn't had a chance to test it yet, but if this works for you I guess I have my case :) > The other question I have is why in ata-dma.c is there the fall through to > the ICH chipset? It seems to prevent any drive actually using ATA100/UDMA5 > features. The fallthrough is just for modes less than ATA100 which is setup the same way as on the ICH therefore the same code.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vm page panic
Hi guys, ok, sources cvsupped yesterday afternoon, just before my ffs_alloc.c commit [which I did, obviously, add myself locally]. Box had been running for a while when all of a sudden it got into a panic: vm_page_alloc: free/cache page 0xc0776fa4 was dirty a trace in ddb shows: allocbuf() getblk() ffs_balloc() ffs_write() vn_rdwr() elf_coredump() coredump() Unfortunately my ata controller didn't get reprobed [just was hanging there] so I couldn't get a crashdump. =( [HPT366] So consider this a heads-up, since you might encounter this. Extra info: devfs running, / is normal FFS /tmp, /var, /usr, /storage all soft-updated. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Pleasure's a sin, and sometimes sin's a pleasure... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
-On [20010325 09:45], Leif Neland ([EMAIL PROTECTED]) wrote: >/var -alldirs -maproot=root: -network 192.168.5 -mask 255.255.255.0 > >But after the portmapper change, I couldn't mount, was getting permission >denied. > >showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 > >Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 >used to work. You can only `compress' leading zeroes IIRC. So it should have had interpreted the .5 as 000.005, not 005.000. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Time will tell everything - given time... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
>From a pure logic point of view here's something that might help you understand it the 4 octets are broken down into binary and then combined without the decimal point. when whatever libraries are doing this, the first octec(192) is converted to binary. Then there is probably some sort of if statement that says if there is only one more octet to process make it the last octet. The reason for this is so you can enter in ip addresses like 3232236800 which is another way of looking at 192.168.5.0, if it wasn't processed like this, it might try to ping 3232236800.0.0.0 If I've caused any more confusion than help, let me know and I can email you in private and help better explain. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
Leif Neland wrote: > > Bug or pilot error? > > My network is 192.168.5.0 > > I used to have im my /etc/exports: > > /var -alldirs -maproot=root: -network 192.168.5 -mask 255.255.255.0 > > But after the portmapper change, I couldn't mount, was getting permission > denied. > > showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 This is the correct interpretation. > > Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 > used to work. It was broken, then. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] all your kernels arpanic: blockable sleep lock (sleep mutex) Giant @ ../../kern/kern_sig.c:153 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
