Re: is 'device ether' mandatory now?
Hello Luigi, On 05:20-0800, Mar 24, 2002, Luigi Rizzo wrote: > Do you have a suggestion for an #ifdef /#endif to > remove the problem you mention ? Frankly speaking, I have no solution atm. But IMHO we should fix LINT and warn our -stable users at least. Something like that: Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v retrieving revision 1.749.2.106 diff -u -r1.749.2.106 LINT --- sys/i386/conf/LINT 2002/03/11 01:23:05 1.749.2.106 +++ sys/i386/conf/LINT 2002/03/26 08:06:56 @@ -468,8 +468,8 @@ # Network interfaces: # The `loop' pseudo-device is MANDATORY when networking is enabled. # The `ether' pseudo-device provides generic code to handle -# Ethernets; it is MANDATORY when a Ethernet device driver is -# configured or token-ring is enabled. +# Ethernets; it is MANDATORY when the Internet communication +# protocols family (INET) is configured. # The 'fddi' pseudo-device provides generic code to support FDDI. # The `arcnet' pseudo-device provides generic code to support Arcnet. # The `sppp' pseudo-device serves a similar role for certain types Index: NOTES === RCS file: /home/ncvs/src/sys/i386/conf/NOTES,v retrieving revision 1.1011 diff -u -r1.1011 NOTES --- NOTES 2002/03/23 18:39:54 1.1011 +++ NOTES 2002/03/26 08:08:48 @@ -521,8 +521,8 @@ # Network interfaces: # The `loop' device is MANDATORY when networking is enabled. # The `ether' device provides generic code to handle -# Ethernets; it is MANDATORY when a Ethernet device driver is -# configured or token-ring is enabled. +# Ethernets; it is MANDATORY when the Internet communication +# protocols family (INET) is configured. # The `fddi' device provides generic code to support FDDI. # The `arcnet' device provides generic code to support Arcnet. # The `sppp' device serves a similar role for certain types %%% I believe handbook is affected too. > cheers > luigi > > On Sat, Mar 23, 2002 at 08:50:19PM +0300, Maxim Konovalov wrote: > > > > Hello, > > > > After this commit 'device ether' is mandatory if ever there is no any > > ethernet or token-ring devices. > > > > | luigi 2002/02/18 14:50:13 PST > > | > > | Modified files: > > |sys/net if.c > > | Log: > > | When the local link address is changed, send out gratuitous ARPs > > | to notify other nodes about the address change. Otherwise, they > > | might try and keep using the old address until their arp table > > | entry times out and the address is refreshed. > > | > > | Maybe this ought to be done for INET6 addresses as well but i have > > | no idea how to do it. It should be pretty straightforward though. > > | > > | MFC-after: 10 days > > | > > | Revision ChangesPath > > | 1.128 +11 -0 src/sys/net/if.c > > > > -- > > Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer > > phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
For review: Revised sendmail startup settings
An issue came up on freebsd-stable today regarding the boot-time startup of
sendmail for users who are using other MTAs. The end result was that users
needed a way to completely prevent sendmail from trying to start at boot
time.
The current order of operations at boot time is:
# MTA
if ${sendmail_enable} == YES
start sendmail with ${sendmail_flags}
else
if ${sendmail_outbound_enable} == YES
start sendmail with ${sendmail_outbound_flags}
if ${sendmail_submit_enable} == YES
start sendmail with ${sendmail_submit_flags}
endif
# MSP Queue Runner
if [ -r /etc/mail/submit.cf] && ${sendmail_msp_queue_enable} == YES
start sendmail with ${sendmail_msp_queue_flags}
endif
A few solutions were discussed and the patch represents what I feel to be
the best solution. Instead of rc.conf's sendmail_enable only accepting YES
or NO, it can now also accept NONE. If set to NONE, none of the other
sendmail related startup items will be done. While creating the patch, I
found an extra queue running daemon might be started that wasn't necessary
(it didn't hurt anything but it wasn't needed). That has been fixed in the
patch as well.
Therefore, the new order of operations (as shown in the rc.conf man page
and src/etc/defaults/rc.conf patches) is:
# MTA
if ${sendmail_enable} == NONE
# Do nothing
else if ${sendmail_enable} == YES
start sendmail with ${sendmail_flags}
else if ${sendmail_submit_enable} == YES
start sendmail with ${sendmail_submit_flags}
else if ${sendmail_outbound_enable} == YES
start sendmail with ${sendmail_outbound_flags}
endif
# MSP Queue Runner
if ${sendmail_enable} != NONE &&
[ -r /etc/mail/submit.cf] && ${sendmail_msp_queue_enable} == YES
start sendmail with ${sendmail_msp_queue_flags}
endif
This will allow users to set sendmail_enable to NONE in /etc/rc.conf and
completely avoid any sendmail daemons.
I've also updated the /etc/mail/Makefile "start" target code to match the
new order of operations and added a new set of targets for the MSP queue
runner (start-mspq, stop-mspq, and restart-mspq).
Unless I hear any good arguments against this change, I'll commit it in the
next day or two (and MFC it a week later).
The patches for the two branches are available at:
FreeBSD 4.5-STABLE: http://people.freebsd.org/~gshapiro/smstart-STABLE
FreeBSD 5.0-CURRENT:http://people.freebsd.org/~gshapiro/smstart-CURRENT
Thanks go to Thomas Quinot <[EMAIL PROTECTED]> and
Christopher Schulte <[EMAIL PROTECTED]> for their
contributions to the idea and Mark Santcroos <[EMAIL PROTECTED]> for reminding
me to update /etc/mail/Makefile with the new startup routines.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
On Mon, 25 Mar 2002, Michael Smith wrote: > Please don't file a PR against something like this in -current until > you've established that it's not a transient problem. > > In this case, it looks like a possibly corrupt kernel; you're dying very > early on after jumping into the kernel. Someone already pointed out, that this problem can be in corrupted kernel floppy image. I have the same problem building release of different dates. Floppies and cdrom install crashes with the same error, but if you try to boot kernel from hdd - all seems to work. I tried to find this dramatic change in release makefiles, but nothing seems to be suspicious to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't build world on alpha
: :On Sun, Mar 24, 2002 at 09:38:42AM -0800, Matthew Dillon wrote: :> :On Sat, Mar 23, 2002 at 11:02:26AM -0800, Matthew Dillon wrote: :> :> Anyone have any ideas? I'm trying to build the latest -current :> :> (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'. : :I just verified one can build last night's (March 24th 3am) -CURRENT on a :Feb 10th' 4.5-STABLE box. Yah. It turned out to be an out of date /usr/share/mk. I guess make installworld doesn't update those files. I can now buildworld successfully and buildkernel doesn't give me the weird global register warning any more. Yahh. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
D-link 660+ PCMCIA + FreeBSD4.5
I have problem with D-link 660+ in FreeBSD. Pccardd say that: "driver not configured, loading driver failed" What should I do?
Re: stdout changes break some ports
On Mon, Mar 25, 2002 at 09:30:39PM -0800, Doug Barton wrote: > On Sun, 24 Mar 2002, Kris Kennaway wrote: > > > OK. Someone needs to go and fix those 84 ports then. > > > > http://bento.freebsd.org/errorlogs/5-latest-4-latest.html > > Has anyone contacted the maintainers? I'm sure that not all of > them are on this list. It may be a good way to get a slightly more > knowledgeable user base exposed to -current, as well as getting the ports > fixed. Yeah, that's something I'm going to do once the current package run finishes. I've held off doing it in the recent past since there were a lot of spurious failures caused by problems with bento, but I think this run is entirely free of such problems, and it's only ports which are truly broken that are showing up. Kris msg36578/pgp0.pgp Description: PGP signature
Re: VMWare2 seems broken in recent -current
Currently rebuilding with latest sources, will look into it after that. Mark On Sat, Mar 23, 2002 at 07:04:02PM -0500, Garance A Drosihn wrote: > I've just upgraded my i386-current box from about March 13 to > a snapshot from late last night. Now when I run vmware, the > vmware program dies with: > > VMware Workstation PANIC: BUG F(571):1607 bugNr=2302 > > when I try to "Power on" some virtual machine. When I got in > today, I cvsup'ed again, removed all of /usr/obj/usr/src, and > did another buildworld/installworld. I'm still getting the > same error. I also rebuilt the vmware2 port, in case it was > some includes-library change. > > Unfortunately I am in today because I have a major deadline > for something on Tuesday (something which I need vmware to > do the testing, of course...), so I do not have the time to > do some binary-search of buildworlds to figure out what > the exact culprit is. (in my case, I can just reboot into > the march-13th snapshot of the system, so this issue isn't > an immediate problem for me) > > But I thought I'd mention it in case someone else is about > to do a buildworld and would need vmware2 working after it. > > -- > Garance Alistair Drosehn= [EMAIL PROTECTED] > Senior Systems Programmer or [EMAIL PROTECTED] > Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stdout changes break some ports
On Sun, 24 Mar 2002, Kris Kennaway wrote: > OK. Someone needs to go and fix those 84 ports then. > > http://bento.freebsd.org/errorlogs/5-latest-4-latest.html Has anyone contacted the maintainers? I'm sure that not all of them are on this list. It may be a good way to get a slightly more knowledgeable user base exposed to -current, as well as getting the ports fixed. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Subscribe
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ntfs causing kernel panic
> It could be this problem is a result of the loadable VFS module bug > hacked/fixed in the tree this morning. Was the NTFS driver being loaded > as a module, or compiled into the kernel? If a loadable module, could you > try compiling it into the kernel, or updating past the fix? If already > compiled in, follow the directions grog pointed at to generate useful > debugging output. Ideally, a copy of the full panic message, stack trace, > and information on what kernel options you linked with so that the symbol > offsets are useful. > The recent vfs fix has fixed it, but thanks for the tips on what information to provide. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ntfs causing kernel panic
On Tue, 26 Mar 2002, Greg 'groggy' Lehey wrote: > On Monday, 25 March 2002 at 9:41:09 -0600, David W. Chapman Jr. wrote: > > Has anyone seen mounting an NTFS drive casing a kernel panic? I'd > > love to give the output, but I'm not sure how to redirect the output > > into a file so I can post it here. > > You need to take a dump and analyse it. There's some stuff in the > handbook about how to do it. It could be this problem is a result of the loadable VFS module bug hacked/fixed in the tree this morning. Was the NTFS driver being loaded as a module, or compiled into the kernel? If a loadable module, could you try compiling it into the kernel, or updating past the fix? If already compiled in, follow the directions grog pointed at to generate useful debugging output. Ideally, a copy of the full panic message, stack trace, and information on what kernel options you linked with so that the symbol offsets are useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ntfs causing kernel panic
On Monday, 25 March 2002 at 9:41:09 -0600, David W. Chapman Jr. wrote: > Has anyone seen mounting an NTFS drive casing a kernel panic? I'd > love to give the output, but I'm not sure how to redirect the output > into a file so I can post it here. You need to take a dump and analyse it. There's some stuff in the handbook about how to do it. Greg -- 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: ntfs causing kernel panic
On Tue, Mar 26, 2002 at 10:08:20AM +1030, Greg 'groggy' Lehey wrote: > On Monday, 25 March 2002 at 9:41:09 -0600, David W. Chapman Jr. wrote: > > Has anyone seen mounting an NTFS drive casing a kernel panic? I'd > > love to give the output, but I'm not sure how to redirect the output > > into a file so I can post it here. > > You need to take a dump and analyse it. There's some stuff in the > handbook about how to do it. > Unfortunately it has been fixed, but I am still planning on looking at the handbook, thanks! -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: witness panic on Alpha
On Mon, Mar 25, 2002 at 04:21:23PM -0500, John Baldwin wrote: > On 25-Mar-2002 Wilko Bulte wrote: > > On Mon, Mar 25, 2002 at 11:40:30AM -0500, John Baldwin wrote: > > > > Looks like a different one: > > > > db> trace > > siointr1() at siointr1+0x17c > > siointr() at siointr+0x40 > > isa_handle_fast_intr() at isa_handle_fast_intr+0x28 > > alpha_dispatch_intr() at alpha_dispatch_intr+0xdc > > interrupt() at interrupt+0x108 > > XentInt() at XentInt+0x28 > > --- interrupt (from ipl 0) --- > > --- user mode --- > > db> > > > > and > > > > db> show locks > > exclusive (spin mutex) sio (0xfc648d20) locked @ > > /usr/src/sys/dev/sio/sio.c:1634 > > db> > > > > This is a serial console > > Hummm, and you got a blockable lock panic here? Well.. I lost the system for a reboot that served as the console display so I cannot tell unfortunately what the panic message said. W/ -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bktr breakage
On Mon, Mar 25, 2002 at 10:21:49PM +0100, Nicolas Souchu wrote: > Hi there, > > *Sorry* for the breakage. I'm currently fixing it. > > smbus.h is due to the missing rule, smbus.h removed from OBJS. > > bktr_i2c.c is due to its automatic inclusion in kernel by conf/files: > conditional compilation inserted. > > pcf.c breakage is due to iicbus_alloc_bus() removed, device_add_child() > inserted instead. > > LINT ok. > GENERIC is compiling... > > I tell you once commited. Done. Thanks guys. Nicholas -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: witness panic on Alpha
On 25-Mar-2002 Wilko Bulte wrote: > On Mon, Mar 25, 2002 at 11:40:30AM -0500, John Baldwin wrote: > > Looks like a different one: > > db> trace > siointr1() at siointr1+0x17c > siointr() at siointr+0x40 > isa_handle_fast_intr() at isa_handle_fast_intr+0x28 > alpha_dispatch_intr() at alpha_dispatch_intr+0xdc > interrupt() at interrupt+0x108 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 0) --- > --- user mode --- > db> > > and > > db> show locks > exclusive (spin mutex) sio (0xfc648d20) locked @ > /usr/src/sys/dev/sio/sio.c:1634 > db> > > This is a serial console Hummm, and you got a blockable lock panic here? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bktr breakage
Hi there, *Sorry* for the breakage. I'm currently fixing it. smbus.h is due to the missing rule, smbus.h removed from OBJS. bktr_i2c.c is due to its automatic inclusion in kernel by conf/files: conditional compilation inserted. pcf.c breakage is due to iicbus_alloc_bus() removed, device_add_child() inserted instead. LINT ok. GENERIC is compiling... I tell you once commited. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken bktr(4) module
* David O'Brien ([EMAIL PROTECTED]) wrote: > > Hmm, I am not alone I see here.. Already filed a PR about it. > > What was the PR number. I already fixed it. For build problem things > like this, emailing the list is better as people will see it MUCH > quicker. kern/36298, but it's already closed. Maxim was quick to spot it. Next time I'll mail the list. I'll save the PR's for the not-really-obvious things then. Actually, the PR was closed quicker than you people replying that the current@ list was quicker. How's that for efficiency? ;-) Cheers, Emiel -- Of all the animals, the boy is the most unmanageable. -- Plato To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Alpha Build
Hi, I have a chance to pick up an Alpha machine which I would use for FreeBSD testing. There are 4 AlphaStation 600's from which I could pick, 2 of them have 'TGA graphics cards', 2 have "normal" graphics cards and "can run X." Seeing as right now I know next to nothing about Alpha's, would it be better to pick one or the other, or, would one or the other be better for freeBSD testing? thanks much, Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: witness panic on Alpha
On Mon, Mar 25, 2002 at 11:40:30AM -0500, John Baldwin wrote: Looks like a different one: db> trace siointr1() at siointr1+0x17c siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x28 alpha_dispatch_intr() at alpha_dispatch_intr+0xdc interrupt() at interrupt+0x108 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- --- user mode --- db> and db> show locks exclusive (spin mutex) sio (0xfc648d20) locked @ /usr/src/sys/dev/sio/sio.c:1634 db> This is a serial console Wilko > > No such command > > db> trace > > Debugger() at Debugger+0x3c > > panic() at panic+0x100 > > witness_lock() at witness_lock+0xb4 > > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > > vfree() at vfree+0x30 > > vm_page_free_toq() at vm_page_free_toq+0x200 > > vm_page_free() at vm_page_free+0x2c > > vm_page_alloc() at vm_page_alloc+0x1ac > > pmap_growkernel() at pmap_growkernel+0x3e8 > > vm_map_findspace() at vm_map_findspace+0x144 > > kmem_alloc() at kmem_alloc+0x9c > > _zget() at _zget+0x244 > > zalloc() at zalloc+0x78 > > getnewvnode() at getnewvnode+0x470 > > ffs_vget() at ffs_vget+0x168 > > ufs_lookup() at ufs_lookup+0xf78 > > ufs_vnoperate() at ufs_vnoperate+0x2c > > vfs_cache_lookup() at vfs_cache_lookup+0x3cc > > ufs_vnoperate() at ufs_vnoperate+0x2c > > lookup() at lookup+0x4d0 > > namei() at namei+0x308 > > lstat() at lstat+0x50 > > syscall() at syscall+0x318 > > XentSys() at XentSys+0x64 > > --- syscall (190, FreeBSD ELF, lstat) --- > > --- user mode --- > > db> > > Is this reproducible? If so, can you do a 'show locks'? -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken bktr(4) module
On Mon, Mar 25, 2002 at 12:14:26PM +0100, Emiel Kollof wrote: > * Crist J. Clark ([EMAIL PROTECTED]) wrote: > > I believe the recent changes to the bktr(4) module Makefile broke it, > > > > ===> bktr > > ===> bktr/bktr > > make: don't know how to make smbus.h. Stop > > *** Error code 2 > > > > Stop in /usr/src/sys/modules/bktr. > > *** Error code 1 > > Hmm, I am not alone I see here.. Already filed a PR about it. What was the PR number. I already fixed it. For build problem things like this, emailing the list is better as people will see it MUCH quicker. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What changed with the resolver such that it won't use /etc/hosts anymore?
David et al, # So what broke this? # -- David ([EMAIL PROTECTED]) Has this been fixed? I observe the same on FreeBSD 5.0-CURRENT #4: Fri Mar 8 19:51:15 CET 2002 and am wondering if a make world would fix this. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
Please don't file a PR against something like this in -current until you've established that it's not a transient problem. In this case, it looks like a possibly corrupt kernel; you're dying very early on after jumping into the kernel. > On Mon, Mar 25, 2002 at 06:05:14AM -0800, Hiten Pandya wrote: > > > Could you please send us the register dump. Someone will analyse it and > > will get back to you. Or could you please file a Problem Report for this > > issue. :) > > Here's the dump, I want to open a PR too, what the category would be? > i386?=20 > > int=3D0006 err=3D efl=3D00010092 eip=3Dc0309927 > eax=3Dc082e000 ebx=3D0082cc00 ecx=3D edx=3D0002 > esi=3D0082c000 edi=3D00834000 ebp=3Dc082fd94 esp=3Dc082fd78 > cs=3D0008 ds=3D0010 es=3D0010 fs=3D0010 gs=3D0010 ss=3D0010 > cs:eip=3Dff ff a1 a4 48 37 c0 a3 - ac aa 38 c0 a1 a8 48 37 >c0 a3 84 ab 38 c0 05 a0 - 1d ff ff a3 60 ab 38 c0 > > ss:esp=3D00 40 83 00 00 00 00 00 - 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 > BTX halted =20 > > Cheers, > --=20 > Miguel Mendez - [EMAIL PROTECTED] > GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt > EnergyHQ :: http://www.energyhq.tk > FreeBSD - The power to serve! > > --3uo+9/B/ebqu+fSQ > Content-Type: application/pgp-signature > Content-Disposition: inline > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iD8DBQE8nzMmnLctrNyFFPERAqwJAKDBOJhFlCqEU8vzLqI9MOfPcn6n9gCfdMmE > 7mlV6vaD/gDqzvaB1szYxD4= > =FJoS > -END PGP SIGNATURE- > > --3uo+9/B/ebqu+fSQ-- > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: witness panic on Alpha
On Mon, Mar 25, 2002 at 11:40:30AM -0500, John Baldwin wrote: > > lstat() at lstat+0x50 > > syscall() at syscall+0x318 > > XentSys() at XentSys+0x64 > > --- syscall (190, FreeBSD ELF, lstat) --- > > --- user mode --- > > db> > > Is this reproducible? If so, can you do a 'show locks'? Sofar it happened once. But I'll try to catch it again. -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
On 25-Mar-2002 Miguel Mendez wrote: > On Mon, Mar 25, 2002 at 11:40:36AM -0500, John Baldwin wrote: >> > int=0006 err= efl=00010092 eip=c0309927 >> > eax=c082e000 ebx=0082cc00 ecx= edx=0002 >> > esi=0082c000 edi=00834000 ebp=c082fd94 esp=c082fd78 >> > cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 >> > cs:eip=ff ff a1 a4 48 37 c0 a3 - ac aa 38 c0 a1 a8 48 37 >> >c0 a3 84 ab 38 c0 05 a0 - 1d ff ff a3 60 ab 38 c0 >> > >> > ss:esp=00 40 83 00 00 00 00 00 - 00 00 00 00 00 00 00 00 >> >00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 >> > BTX halted >> >> Weird, it looks like you actually got into the kernel before blowing up. >> Did you have debug copy of the kernel with you. If so, can you do a >> listing of the address in %eip? > > I don't have a debug kernel, those are the boot floppies downloaded from > current.freebsd.org. If it helps, the snapshot floppies from 11th of > March work, every floppy made after that date fails with the same error. > I'm going to install that snapshot, upgrade the system and try to > reproduce the error with a debug kernel. Ok. If you can figure out what kernel commit broke things that would be very helpful. Thanks! -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT/NOTES broken after recent bktr(4) change
>Date: Mon, 25 Mar 2002 08:43:30 -0800 (PST) >From: David Wolfskill <[EMAIL PROTECTED]> >linking kernel.debug >pcf.o: In function `pcf_attach': >/usr/src/sys/i386/isa/pcf.c(.text+0x1f1): undefined reference to `iicbus_alloc_bus' >*** Error code 1 >Looks to me like a declaration & a reference, but no definition. OK; I was able to get past this point by reverting src/sys/dev/iicbus/iiconf.c frlom 1.13 to 1.12. (The 1.12 version of the file had a definition of iicbus_alloc_bus() that the 1.13 change removed.) Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_dc broken in -current
On Mon, 25 Mar 2002, Ilmar S. Habibulin wrote: > On Mon, 25 Mar 2002, Stephen McKay wrote: > > > What sort of card do you have? The output of dmesg would help. Have you > > tried 4.5 on this machine? > I have some noname nic with Intel 21143 chip. dmesg attached. I'm using > only trustedbsd_mac branch on my ws. > > > Of course the dc driver should autonegotiate (and does so when I revert > > rev 1.56). Your info could help trace this problem. > Well, i don't think this is the problem. Hardware became too much > inteligent now a days, so one have to use his own hands to make this > hardware work like user wants it to work. Maybe just put some FAQ about > dc(4) and autoconfigurable hubs/switches? I think I have an identical problem involving a Linksys ethernet card using if_dc. I have to force it to negotiate 10mbps, since it fails to negotiate anything higher with my 10/100 switch. No idea why at all. dc0: port 0xe800-0xe8ff mem 0xfebfff00-0xfebf irq 10 at device 19.0 on pci0 dc0: Ethernet address: 00:a0:cc:35:3e:56 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: flags=8843 mtu 1500 inet6 fe80::2a0:ccff:fe35:3e56%dc0 prefixlen 64 scopeid 0x1 inet 192.168.11.150 netmask 0xff00 broadcast 192.168.11.255 ether 00:a0:cc:35:3e:56 media: Ethernet 10baseT/UTP status: active If I set it to auto-negotiate or hard-set to 100mbps, no packets go back or forth. I've had this problem for at least a year, if not longer. I have the same problem with 4.4-STABLE using an identical card on different hardware: if it tries to negotiate 100mbps, then it simply doesn't work. If I force it to 10, it's fine. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
On Mon, Mar 25, 2002 at 11:40:36AM -0500, John Baldwin wrote: > > int=0006 err= efl=00010092 eip=c0309927 > > eax=c082e000 ebx=0082cc00 ecx= edx=0002 > > esi=0082c000 edi=00834000 ebp=c082fd94 esp=c082fd78 > > cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 > > cs:eip=ff ff a1 a4 48 37 c0 a3 - ac aa 38 c0 a1 a8 48 37 > >c0 a3 84 ab 38 c0 05 a0 - 1d ff ff a3 60 ab 38 c0 > > > > ss:esp=00 40 83 00 00 00 00 00 - 00 00 00 00 00 00 00 00 > >00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 > > BTX halted > > Weird, it looks like you actually got into the kernel before blowing up. > Did you have debug copy of the kernel with you. If so, can you do a > listing of the address in %eip? I don't have a debug kernel, those are the boot floppies downloaded from current.freebsd.org. If it helps, the snapshot floppies from 11th of March work, every floppy made after that date fails with the same error. I'm going to install that snapshot, upgrade the system and try to reproduce the error with a debug kernel. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg36554/pgp0.pgp Description: PGP signature
Re: LINT/NOTES broken after recent bktr(4) change
>Date: Mon, 25 Mar 2002 00:59:37 -0800 >From: Brooks Davis <[EMAIL PROTECTED]> >FWIW, if you uncomment "option BKTR_USE_FREEBSD_SMBUS" in NOTES, the >resulting LINT will compile. Unfortunatly, it won't link due to a >different error related to this commit that I haven't tracked down. Would that, perhaps, be similar to: linking kernel.debug pcf.o: In function `pcf_attach': /usr/src/sys/i386/isa/pcf.c(.text+0x1f1): undefined reference to `iicbus_alloc_bus' *** Error code 1 Stop in /common/S3/obj/usr/src/sys/LAPTOP_30W. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. g1-9(5.0-C)[2] ? If so, I just did a search through my -CURENT /usr/src/sys, loooking for "iicbus_alloc_bus". Results aren't too promising: ./dev/iicbus/iiconf.h:102:extern device_t iicbus_alloc_bus(device_t); ./i386/isa/pcf.c:200: pcf->iicbus = iicbus_alloc_bus(pcfdev); Looks to me like a declaration & a reference, but no definition. :-(, david -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: witness panic on Alpha
On 23-Mar-2002 Wilko Bulte wrote: > Fri Mar 22 19:06:37 CET 2002 > > FreeBSD/alpha (ds10.wbnet) (ttyd0) > > login: syslogd: /var/log/auth.log: No such file or directory > syslogd: /var/log/auth.log: No such file or directory > Mar 22 21:55:23 ds10 kernel: pid 27885 (telnetd), uid 0: exited on signal 11 > (co > re dumped) > Mar 22 21:55:30 ds10 kernel: pid 28342 (telnetd), uid 0: exited on signal 11 > (co > re dumped) > syslogd: /var/log/auth.log: No such file or directory > syslogd: /var/log/auth.log: No such file or directory > panic: blockable sleep lock (sleep mutex) vnode_free_list @ > /usr/src/sys/kern/vf > s_subr.c:2678 > panic > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > db> > db> tb > No such command > db> bt > No such command > db> st > Stopped at Debugger+0x38: call_pal osf1_swpipl > db> stack > No such command > db> trace > Debugger() at Debugger+0x3c > panic() at panic+0x100 > witness_lock() at witness_lock+0xb4 > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > vfree() at vfree+0x30 > vm_page_free_toq() at vm_page_free_toq+0x200 > vm_page_free() at vm_page_free+0x2c > vm_page_alloc() at vm_page_alloc+0x1ac > pmap_growkernel() at pmap_growkernel+0x3e8 > vm_map_findspace() at vm_map_findspace+0x144 > kmem_alloc() at kmem_alloc+0x9c > _zget() at _zget+0x244 > zalloc() at zalloc+0x78 > getnewvnode() at getnewvnode+0x470 > ffs_vget() at ffs_vget+0x168 > ufs_lookup() at ufs_lookup+0xf78 > ufs_vnoperate() at ufs_vnoperate+0x2c > vfs_cache_lookup() at vfs_cache_lookup+0x3cc > ufs_vnoperate() at ufs_vnoperate+0x2c > lookup() at lookup+0x4d0 > namei() at namei+0x308 > lstat() at lstat+0x50 > syscall() at syscall+0x318 > XentSys() at XentSys+0x64 > --- syscall (190, FreeBSD ELF, lstat) --- > --- user mode --- > db> Is this reproducible? If so, can you do a 'show locks'? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
On 25-Mar-2002 Miguel Mendez wrote: > On Mon, Mar 25, 2002 at 06:05:14AM -0800, Hiten Pandya wrote: > >> Could you please send us the register dump. Someone will analyse it and >> will get back to you. Or could you please file a Problem Report for this >> issue. :) > > Here's the dump, I want to open a PR too, what the category would be? > i386? > > int=0006 err= efl=00010092 eip=c0309927 > eax=c082e000 ebx=0082cc00 ecx= edx=0002 > esi=0082c000 edi=00834000 ebp=c082fd94 esp=c082fd78 > cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 > cs:eip=ff ff a1 a4 48 37 c0 a3 - ac aa 38 c0 a1 a8 48 37 >c0 a3 84 ab 38 c0 05 a0 - 1d ff ff a3 60 ab 38 c0 > > ss:esp=00 40 83 00 00 00 00 00 - 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 > BTX halted Weird, it looks like you actually got into the kernel before blowing up. Did you have debug copy of the kernel with you. If so, can you do a listing of the address in %eip? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Peculiar(?) slowdown with -CURRENT as of 21 March
On 23-Mar-2002 Jeff Roberson wrote: >> >> I saw some similar weirdness in my test machines last night where a dual >> processor DS20 (Alpha 21264 500x2) beat out a PII Xeon 450x4. Normally > the >> quad xeon beats the DS20. The quad xeon was using -j16 but was about 74% >> idle. >> The DS20 had used -j8. I didn't get a chacne to run top to see how it was >> doing during hte world since I didn't notice the weirdness until last > night >> after the DS20 had finsihed but the quad xeon was still chugging along. >> > > Are you both running with WITNESS and INVARIANTS? UMA is slightly slower > with these options on than the original malloc & vm_zone code. I'm not > sure why it would be even worse for SMP machines though. So maybe it > isn't UMA at all but it's worth looking into. Yes. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
Well, here's a dump from me too, it's 5.0-CURRENT-20020313-JPSNAP, the first snap from snapshots.jp.freebsd.org which has the problem. int=0006 err= efl=0006 eip=c03069d7 eax=0081 ebx=0082fc00 ecx= edx=0102 esi=0082f000 edi=00837000 ebp=c0832d94 esp=c0832d94 cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010 cs:eip=ff ff 18 57 56 53 a1 44-15 37 c0 a3 c4 76 38 c0 a1 48 15 37 c0 a3 7c 77-38 c0 05 a0 1d ff ff a3 ss:esp=00 00 00 00 94 93 12 c0-00 70 83 00 00 f0 82 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted > > Could you please send us the register dump. Someone will analyse it and will get > back to you. Or could you please file a Problem Report for this issue. :) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ntfs causing kernel panic
Has anyone seen mounting an NTFS drive casing a kernel panic? I'd love to give the output, but I'm not sure how to redirect the output into a file so I can post it here. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ports broken by OpenPAM
On Mon, 2002-03-25 at 10:00, Dag-Erling Smorgrav wrote:
> Joe Clarke <[EMAIL PROTECTED]> writes:
> > Really? I never received it. Please send it again. Thanks.
>
> Here's an updated (but untested) version.
Thanks. As soon as I finish get my -current machine built, I'll test
these out.
Joe
>
> DES
> --
> Dag-Erling Smorgrav - [EMAIL PROTECTED]
>
>
>
> --- pam_ldap.c.orig Mon Mar 25 15:54:28 2002
> +++ pam_ldap.cMon Mar 25 15:54:29 2002
> @@ -126,12 +126,7 @@
> #include "pam_ldap.h"
> #include "md5.h"
>
> -#ifdef HAVE_SECURITY_PAM_MISC_H
> - /* FIXME: is there something better to check? */
> #define CONST_ARG const
> -#else
> -#define CONST_ARG
> -#endif
>
> #ifndef HAVE_LDAP_MEMFREE
> #define ldap_memfree(x) free(x)
> @@ -2843,11 +2838,11 @@
> {
> _conv_sendmsg (appconv, "Password change aborted",
>PAM_ERROR_MSG, no_warn);
> -#ifdef PAM_AUTHTOK_RECOVERY_ERR
> - return PAM_AUTHTOK_RECOVERY_ERR;
> -#else
> +#ifdef PAM_AUTHTOK_RECOVER_ERR
> return PAM_AUTHTOK_RECOVER_ERR;
> -#endif /* PAM_AUTHTOK_RECOVERY_ERR */
> +#else
> + return PAM_AUTHTOK_RECOVERY_ERR;
> +#endif /* PAM_AUTHTOK_RECOVER_ERR */
> }
> else
> {
> @@ -2887,11 +2882,11 @@
>syslog (LOG_ERR,
> "pam_ldap: error getting old authentication token (%s)",
> pam_strerror (pamh, rc));
> -#ifdef PAM_AUTHTOK_RECOVERY_ERR
> - return PAM_AUTHTOK_RECOVERY_ERR;
> -#else
> +#ifdef PAM_AUTHTOK_RECOVER_ERR
>return PAM_AUTHTOK_RECOVER_ERR;
> -#endif /* PAM_AUTHTOK_RECOVERY_ERR */
> +#else
> + return PAM_AUTHTOK_RECOVERY_ERR;
> +#endif /* PAM_AUTHTOK_RECOVER_ERR */
> }
>
>if (try_first_pass || use_first_pass)
> @@ -2901,11 +2896,11 @@
> newpass = NULL;
>
>if (use_first_pass && newpass == NULL)
> -#ifdef PAM_AUTHTOK_RECOVERY_ERR
> - return PAM_AUTHTOK_RECOVERY_ERR;
> -#else
> +#ifdef PAM_AUTHTOK_RECOVER_ERR
> return PAM_AUTHTOK_RECOVER_ERR;
> -#endif /* PAM_AUTHTOK_RECOVERY_ERR */
> +#else
> + return PAM_AUTHTOK_RECOVERY_ERR;
> +#endif /* PAM_AUTHTOK_RECOVER_ERR */
> }
>
>tries = 0;
> @@ -2955,11 +2950,11 @@
> }
>else
> {
> -#ifdef PAM_AUTHTOK_RECOVERY_ERR
> - return PAM_AUTHTOK_RECOVERY_ERR;
> -#else
> +#ifdef PAM_AUTHTOK_RECOVER_ERR
> return PAM_AUTHTOK_RECOVER_ERR;
> -#endif /* PAM_AUTHTOK_RECOVERY_ERR */
> +#else
> + return PAM_AUTHTOK_RECOVERY_ERR;
> +#endif /* PAM_AUTHTOK_RECOVER_ERR */
> }
>
>if (cmiscptr == NULL)
> @@ -2991,11 +2986,11 @@
> {
> _conv_sendmsg (appconv, "Password change aborted",
>PAM_ERROR_MSG, no_warn);
> -#ifdef PAM_AUTHTOK_RECOVERY_ERR
> - return PAM_AUTHTOK_RECOVERY_ERR;
> -#else
> +#ifdef PAM_AUTHTOK_RECOVER_ERR
> return PAM_AUTHTOK_RECOVER_ERR;
> -#endif /* PAM_AUTHTOK_RECOVERY_ERR */
> +#else
> + return PAM_AUTHTOK_RECOVERY_ERR;
> +#endif /* PAM_AUTHTOK_RECOVER_ERR */
> }
> }
> else if (!strcmp (newpass, miscptr))
signature.asc
Description: This is a digitally signed message part
Re: if_dc broken in -current
On Mon, 25 Mar 2002, Stephen McKay wrote: > What sort of card do you have? The output of dmesg would help. Have you > tried 4.5 on this machine? I have some noname nic with Intel 21143 chip. dmesg attached. I'm using only trustedbsd_mac branch on my ws. > Of course the dc driver should autonegotiate (and does so when I revert > rev 1.56). Your info could help trace this problem. Well, i don't think this is the problem. Hardware became too much inteligent now a days, so one have to use his own hands to make this hardware work like user wants it to work. Maybe just put some FAQ about dc(4) and autoconfigurable hubs/switches? Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-TrustedBSD #5: Mon Mar 25 15:45:32 MSK 2002 root@ws-ilmar:/usr/tmp/tt/mac/sys/i386/compile/WS_ILMAR Preloaded elf kernel "/boot/kernel/kernel" at 0xc03e3000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03e30a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 706293487 Hz CPU: AMD Duron(tm) Processor (706.29-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 Features=0x183f9ff AMD Features=0xc044 real memory = 134135808 (130992K bytes) avail memory = 126418944 (123456K bytes) Security policy: TrustedBSD MAC/BSD Extended (trustedbsd_mac_bsdextended) Security policy: TrustedBSD MAC/Biba (trustedbsd_mac_biba) Security policy: TrustedBSD MAC/MLS (trustedbsd_mac_mls) Security policy: TrustedBSD MAC/TE (trustedbsd_mac_te) Security policy: TrustedBSD MAC/None (trustedbsd_mac_none) Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00f1720 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 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) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xb400-0xb41f irq 5 at device 4.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 uhci1: port 0xb000-0xb01f irq 5 at device 4.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 dc0: port 0x9400-0x947f mem 0xde80-0xde8003ff irq 10 at device 11.0 on pci0 dc0: Ethernet address: 00:80:ad:90:b4:38 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: initialized as trusted interface fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77b,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 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 lp0: initialized as untrusted interface sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model NetMouse/NetScroll Optical, device ID 0 orm0: at iomem 0xc-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 lo0: intialized as localhost interface IPsec: Initialized Security Association Processing. acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% ad0: 9797MB [19906/16/63] at ata0-master UDMA100 Mounting root from ufs:/dev/ad0s1a pid 230 (getpmac), uid 1001: exited on signal 11 (core dumped)
Re: Ports broken by OpenPAM
Joe Clarke <[EMAIL PROTECTED]> writes:
> Really? I never received it. Please send it again. Thanks.
Here's an updated (but untested) version.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
--- pam_ldap.c.orig Mon Mar 25 15:54:28 2002
+++ pam_ldap.c Mon Mar 25 15:54:29 2002
@@ -126,12 +126,7 @@
#include "pam_ldap.h"
#include "md5.h"
-#ifdef HAVE_SECURITY_PAM_MISC_H
- /* FIXME: is there something better to check? */
#define CONST_ARG const
-#else
-#define CONST_ARG
-#endif
#ifndef HAVE_LDAP_MEMFREE
#define ldap_memfree(x) free(x)
@@ -2843,11 +2838,11 @@
{
_conv_sendmsg (appconv, "Password change aborted",
PAM_ERROR_MSG, no_warn);
-#ifdef PAM_AUTHTOK_RECOVERY_ERR
- return PAM_AUTHTOK_RECOVERY_ERR;
-#else
+#ifdef PAM_AUTHTOK_RECOVER_ERR
return PAM_AUTHTOK_RECOVER_ERR;
-#endif /* PAM_AUTHTOK_RECOVERY_ERR */
+#else
+ return PAM_AUTHTOK_RECOVERY_ERR;
+#endif /* PAM_AUTHTOK_RECOVER_ERR */
}
else
{
@@ -2887,11 +2882,11 @@
syslog (LOG_ERR,
"pam_ldap: error getting old authentication token (%s)",
pam_strerror (pamh, rc));
-#ifdef PAM_AUTHTOK_RECOVERY_ERR
- return PAM_AUTHTOK_RECOVERY_ERR;
-#else
+#ifdef PAM_AUTHTOK_RECOVER_ERR
return PAM_AUTHTOK_RECOVER_ERR;
-#endif /* PAM_AUTHTOK_RECOVERY_ERR */
+#else
+ return PAM_AUTHTOK_RECOVERY_ERR;
+#endif /* PAM_AUTHTOK_RECOVER_ERR */
}
if (try_first_pass || use_first_pass)
@@ -2901,11 +2896,11 @@
newpass = NULL;
if (use_first_pass && newpass == NULL)
-#ifdef PAM_AUTHTOK_RECOVERY_ERR
- return PAM_AUTHTOK_RECOVERY_ERR;
-#else
+#ifdef PAM_AUTHTOK_RECOVER_ERR
return PAM_AUTHTOK_RECOVER_ERR;
-#endif /* PAM_AUTHTOK_RECOVERY_ERR */
+#else
+ return PAM_AUTHTOK_RECOVERY_ERR;
+#endif /* PAM_AUTHTOK_RECOVER_ERR */
}
tries = 0;
@@ -2955,11 +2950,11 @@
}
else
{
-#ifdef PAM_AUTHTOK_RECOVERY_ERR
- return PAM_AUTHTOK_RECOVERY_ERR;
-#else
+#ifdef PAM_AUTHTOK_RECOVER_ERR
return PAM_AUTHTOK_RECOVER_ERR;
-#endif /* PAM_AUTHTOK_RECOVERY_ERR */
+#else
+ return PAM_AUTHTOK_RECOVERY_ERR;
+#endif /* PAM_AUTHTOK_RECOVER_ERR */
}
if (cmiscptr == NULL)
@@ -2991,11 +2986,11 @@
{
_conv_sendmsg (appconv, "Password change aborted",
PAM_ERROR_MSG, no_warn);
-#ifdef PAM_AUTHTOK_RECOVERY_ERR
- return PAM_AUTHTOK_RECOVERY_ERR;
-#else
+#ifdef PAM_AUTHTOK_RECOVER_ERR
return PAM_AUTHTOK_RECOVER_ERR;
-#endif /* PAM_AUTHTOK_RECOVERY_ERR */
+#else
+ return PAM_AUTHTOK_RECOVERY_ERR;
+#endif /* PAM_AUTHTOK_RECOVER_ERR */
}
}
else if (!strcmp (newpass, miscptr))
Re: Ports broken by OpenPAM
On 25 Mar 2002, Dag-Erling Smorgrav wrote: > Kris Kennaway <[EMAIL PROTECTED]> writes: > > bftpd-1.0.22.log > > pam-pgsql-0.5.2_2.log > > Not tested. > > > pam_ldap-1.4.0.log > > Not my problem; I sent the maintainer a patch ages ago. Really? I never received it. Please send it again. Thanks. Joe [snip] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ports broken by OpenPAM
Kris Kennaway <[EMAIL PROTECTED]> writes: > bftpd-1.0.22.log > pam-pgsql-0.5.2_2.log Not tested. > pam_ldap-1.4.0.log Not my problem; I sent the maintainer a patch ages ago. > pam_mysql-0.4.7.log Not tested. > pam_ssh-1.5.log This port should die, pam_ssh(8) is in the base system and the port is way out of date. > samba-3.0a15.log See previous mail. > vlock-1.3.log Not tested. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
On Mon, Mar 25, 2002 at 06:05:14AM -0800, Hiten Pandya wrote: > Could you please send us the register dump. Someone will analyse it and > will get back to you. Or could you please file a Problem Report for this > issue. :) Here's the dump, I want to open a PR too, what the category would be? i386? int=0006 err= efl=00010092 eip=c0309927 eax=c082e000 ebx=0082cc00 ecx= edx=0002 esi=0082c000 edi=00834000 ebp=c082fd94 esp=c082fd78 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=ff ff a1 a4 48 37 c0 a3 - ac aa 38 c0 a1 a8 48 37 c0 a3 84 ab 38 c0 05 a0 - 1d ff ff a3 60 ab 38 c0 ss:esp=00 40 83 00 00 00 00 00 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 BTX halted Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg36544/pgp0.pgp Description: PGP signature
Re: BTX halted
--- Miguel Mendez <[EMAIL PROTECTED]> wrote: > Hi, > > I've tried to install two snapshots (20th and 21st of March) on my > Thinkpad laptop, and after the loader has finished reading mfsroot.flp I > get a register dump and a message saying BTX halted. Any hints of what > could be causing this? The problem didn't show last time I used a > snapshost, last December or 4.5-R install disks. Hi Miguel, Could you please send us the register dump. Someone will analyse it and will get back to you. Or could you please file a Problem Report for this issue. :) Thanks, Regards, -- Hiten Pandya -- <[EMAIL PROTECTED]> __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
BTX halted
Hi, I've tried to install two snapshots (20th and 21st of March) on my Thinkpad laptop, and after the loader has finished reading mfsroot.flp I get a register dump and a message saying BTX halted. Any hints of what could be causing this? The problem didn't show last time I used a snapshost, last December or 4.5-R install disks. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg36542/pgp0.pgp Description: PGP signature
Re: if_dc broken in -current
On Friday, 22nd March 2002, "Ilmar S. Habibulin" wrote: >On Sat, 23 Mar 2002, Stephen McKay wrote: > >> It's been quite a while since I updated my -current box, but when I did, >> I was surprised to find that my DE500 network card (21143 chip) had stopped >> working. The switch showed no link. Ifconfig showed "no carrier". > >I've had the simular problem. Now i have media option set to needed value >in ifconfig_dc0 variable. This helped. What sort of card do you have? The output of dmesg would help. Have you tried 4.5 on this machine? Of course the dc driver should autonegotiate (and does so when I revert rev 1.56). Your info could help trace this problem. Stephen. PS I'm now assuming the number of -current users that use PNIC and Davicom cards with the dc driver is exactly zero. Oh well. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken bktr(4) module
* Crist J. Clark ([EMAIL PROTECTED]) wrote: > I believe the recent changes to the bktr(4) module Makefile broke it, > > ===> bktr > ===> bktr/bktr > make: don't know how to make smbus.h. Stop > *** Error code 2 > > Stop in /usr/src/sys/modules/bktr. > *** Error code 1 Hmm, I am not alone I see here.. Already filed a PR about it. Cheers, Emiel -- The universe is like a safe to which there is a combination -- but the combination is locked up in the safe. -- Peter DeVries To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT/NOTES broken after recent bktr(4) change
On Mon, Mar 25, 2002 at 03:28:19AM -0500, Mike Barcroft wrote: > > I think I've narrowed down the problem: > : revision 1.20 > : date: 2002/03/23 15:47:08; author: nsouch; state: Exp; lines: +112 -192 > : Major rework of the iicbus/smbus framework: > : > : - VIA chipset SMBus controllers added > : - alpm driver updated > : - Support for dynamic modules added > : - bktr FreeBSD smbus updated but not tested > ^ > : - cleanup FWIW, if you uncomment "option BKTR_USE_FREEBSD_SMBUS" in NOTES, the resulting LINT will compile. Unfortunatly, it won't link due to a different error related to this commit that I haven't tracked down. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg36539/pgp0.pgp Description: PGP signature
LINT/NOTES broken after recent bktr(4) change
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/work/src/sys -I/work/src/sys/dev -I/work/src/sys/contrib/dev/acpica -I/work/src/sys/contrib/ipfilter -I/work/src/sys/../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue /work/src/sys/dev/bktr/bktr_i2c.c /work/src/sys/dev/bktr/bktr_i2c.c: In function `bt848_i2c_attach': /work/src/sys/dev/bktr/bktr_i2c.c:87: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:92: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:93: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:101: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:103: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c: In function `bt848_i2c_detach': /work/src/sys/dev/bktr/bktr_i2c.c:113: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:119: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:119: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:122: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:122: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c: In function `bti2c_smb_callback': /work/src/sys/dev/bktr/bktr_i2c.c:132: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:141: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:142: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:149: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:150: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c: In function `bti2c_iic_callback': /work/src/sys/dev/bktr/bktr_i2c.c:165: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:174: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:175: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:182: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:183: dereferencing pointer to incomplete type *** Error code 1 I think I've narrowed down the problem: : revision 1.20 : date: 2002/03/23 15:47:08; author: nsouch; state: Exp; lines: +112 -192 : Major rework of the iicbus/smbus framework: : : - VIA chipset SMBus controllers added : - alpm driver updated : - Support for dynamic modules added : - bktr FreeBSD smbus updated but not tested ^ : - cleanup Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
