Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

stable-digest V5 #787

4 views

Skip to first unread message

owner-freebsd...@freebsd.org

unread,

Feb 7, 2003, 12:36:35 PM2/7/03

stable-digest Friday, February 7 2003 Volume 05 : Number 787

In this issue:
another crash with 4.7-STABLE
Re: another crash with 4.7-STABLE
ip_output args changed, added a struct inpcb ...
Re: wi0: wi_cmd: busy bit won't clear
AHC/D debug options in GENERIC...?
Re: AHC/D debug options in GENERIC...?
=?ISO-8859-1?B?pc6k36zdp7mz4SEhIS4uLi4u?=
[none]
Re: ip_output args changed, added a struct inpcb ...
ahd1: PCI error interrupt
RE: ahd1: PCI error interrupt
Re: wi0: wi_cmd: busy bit won't clear
SPAM: [Sender DNS] Re: wi_cmd: busy bit won't clear
SPAM: [Sender DNS] Re: wi_cmd: busy bit won't clear
Re: wi0: wi_cmd: busy bit won't clear
Re: wi0: wi_cmd: busy bit won't clear
Re: wi0: wi_cmd: busy bit won't clear
Invalid ps start time values for kernel processes ?
Re: wi0: wi_cmd: busy bit won't clear
Re: wi0: wi_cmd: busy bit won't clear
OpenSSH_3.5p1 FreeBSD-20030201 crash
mpd 3.11 problems?
Problems with pam_ssh(8) and ssh-agent(1) after the OpenSSH upgrade
Re: Invalid ps start time values for kernel processes ?
Re: Problems with pam_ssh(8) and ssh-agent(1) after the OpenSSH upgrade
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
refinance now

----------------------------------------------------------------------

Date: Thu, 6 Feb 2003 11:33:35 -0600
From: Mark Nipper <ni...@tamu.edu>
Subject: another crash with 4.7-STABLE

Well, I should have learned my lesson, but I didn't. I
had a seemingly stable running kernel which was using code from
CVS (using RELENG_4) from around Wed Dec 18 16:01:04 CST 2002
until just a couple of days ago when I still hadn't seen the
sporadic crashes which I'd been seeing.

SO, I figured that whatever was wrong with versions prior
to that had been fixed and I decided to update to the latest
STABLE again, just for the hell of it. BIG MISTAKE. :(

So, I was running STABLE from around Tue Feb 4 10:46:08
CST 2003 for just about two days (1d21h12m2s to be exact) and
oops, it crashed. Here's all the info:
- ---

t@ops/p0:/home/crash> gdb -k kernel.debug.1 vmcore.1
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read cal=
led at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxrea=
d.c line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../..=
/contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf

IdlePTD at phsyical address 0x0031d000
initial pcb at physical address 0x00297be0
panicstr: vm_page_remove(): page not found in hash
panic messages:
- ---
panic: vm_page_remove(): page not found in hash

syncing disks... 19 5 5 5 5 5 5 5 11 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 =
4=20
done
Uptime: 1d21h12m2s

dumping to dev #ad/0x20009, offset 2350209
dump ata0: resetting devices .. done
768 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751 750=
749 748 747 746 745 744 743 742 741 740 739 738 737 736 735 734 733 732 73=
1 730 729 728 727 726 725 724 723 722 721 720 719 718 717 716 715 714 713 7=
12 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694 =
693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 675=
674 673 672 671 670 669 668 667 666 665 664 663 662 661 660 659 658 657 65=
6 655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 6=
37 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619 =
618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600=
599 598 597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 58=
1 580 579 578 577 576 575 574 573 572 571 570 569 568 567 566 565 564 563 5=
62 561 560 559 558 557 556 555 554 553 552 551 550 549 548 547 546 545 544 =
543 542 541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525=
524 523 522 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 50=
6 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 4=
87 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 =
468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450=
449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 43=
1 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 4=
12 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 =
393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375=
374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 35=
6 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 3=
37 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 =
318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300=
299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 28=
1 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 2=
62 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 =
243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225=
224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 20=
6 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 1=
87 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 =
168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150=
149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 13=
1 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 1=
12 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 =
91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 =
66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 =
41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 =
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1=20
- ---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc015e27f in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c:3=
16
#2 0xc015e6a4 in poweroff_wait (junk=3D0xc0268d20, howto=3D-1066573980) at=
/usr/src/sys/kern/kern_shutdown.c:595
#3 0xc02146c7 in vm_page_remove (m=3D0xc06d5f64) at /usr/src/sys/vm/vm_pag=
e.c:460
#4 0xc0214d48 in vm_page_free_toq (m=3D0xc06d5f64) at /usr/src/sys/vm/vm_p=
age.c:1103
#5 0xc0214a51 in vm_page_alloc (object=3D0xe221dd80, pindex=3D430904, page=
_req=3D2) at /usr/src/sys/vm/vm_page.h:514
#6 0xc0185e9a in allocbuf (bp=3D0xd2874590, size=3D16384) at /usr/src/sys/=
kern/vfs_bio.c:2517
#7 0xc0185a7a in getblk (vp=3D0xe2b83c80, blkno=3D107726, size=3D16384, sl=
pflag=3D0, slptimeo=3D0) at /usr/src/sys/kern/vfs_bio.c:2292
#8 0xc018822e in cluster_rbuild (vp=3D0xe2b83c80, filesize=3D4692049920, l=
bn=3D107724, blkno=3D648435200, size=3D16384, run=3D4, fbp=3D0x0)
at /usr/src/sys/kern/vfs_cluster.c:400
#9 0xc0187e8f in cluster_read (vp=3D0xe2b83c80, filesize=3D4692049920, lbl=
kno=3D107724, size=3D16384, cred=3D0x0, totread=3D4096,=20
seqcount=3D110, bpp=3D0xe1c22c4c) at /usr/src/sys/kern/vfs_cluster.c:228
#10 0xc0201ffa in ffs_read (ap=3D0xe1c22ce4) at /usr/src/sys/ufs/ufs/ufs_re=
adwrite.c:253
#11 0xc01c2868 in nfsrv_read (nfsd=3D0xc6361100, slp=3D0xc6159900, procp=3D=
0xdd1bc400, mrq=3D0xe1c22dfc) at vnode_if.h:334
#12 0xc01daf16 in nfssvc_nfsd (nsd=3D0xe1c22e58, argp=3D0x807e100 "", p=3D0=
xdd1bc400) at /usr/src/sys/nfs/nfs_syscalls.c:602
#13 0xc01da871 in nfssvc (p=3D0xdd1bc400, uap=3D0xe1c22f80) at /usr/src/sys=
/nfs/nfs_syscalls.c:306
#14 0xc023b6c5 in syscall2 (frame=3D{tf_fs =3D 47, tf_es =3D 47, tf_ds =3D =
47, tf_edi =3D 0, tf_esi =3D 0, tf_ebp =3D -1077936768,=20
tf_isp =3D -507367468, tf_ebx =3D 9, tf_edx =3D 1, tf_ecx =3D -3, tf_=
eax =3D 155, tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D 134518528,=20
tf_cs =3D 31, tf_eflags =3D 659, tf_esp =3D -1077937196, tf_ss =3D 47=
}) at /usr/src/sys/i386/i386/trap.c:1175
#15 0xc022f7f5 in Xint0x80_syscall ()
#16 0x804813e in ?? ()

And here's dmesg:
- ---
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.7-STABLE #0: Tue Feb 4 10:46:08 CST 2003
ro...@ops.tamu.edu:/usr/obj/usr/src/sys/OPS
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 1611826293 Hz
CPU: AMD Athlon(tm) XP 1900+ (1611.83-MHz 686-class CPU)
Origin =3D "AuthenticAMD" Id =3D 0x662 Stepping =3D 2
Features=3D0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,=
CMOV,PAT,PSE36,MMX,FXSR,SSE>
AMD Features=3D0xc0480000<MP,AMIE,DSP,3DNow!>
real memory =3D 805306368 (786432K bytes)
config> q
avail memory =3D 779898880 (761620K bytes)
Preloaded elf kernel "kernel" at 0xc02fe000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02fe09c.
Pentium Pro MTRR support enabled
Using $PIR table, 6 entries at 0xc00fdf10
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <PCI to PCI bridge (vendor=3D1106 device=3Db099)> at device 1.0 on p=
ci0
pci1: <PCI bus> on pcib1
pci1: <ATI model 5446 graphics accelerator> at 0.0 irq 15
pcib2: <PCI to PCI bridge (vendor=3D1044 device=3Da500)> at device 10.0 on =
pci0
pci2: <PCI bus> on pcib2
asr0: <Adaptec Caching SCSI RAID> mem 0xe8000000-0xe9ffffff irq 10 at devic=
e 10.1 on pci0
asr0: major=3D154
asr0: ADAPTEC 2400A FW Rev. 370L, 4 channel, 256 CCBs, Protocol I2O
fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xe000-0xe03f mem 0xed000000-0=
xed01ffff,0xed020000-0xed020fff irq 11 at device 11.0 on=20
pci0
fxp0: Ethernet address 00:02:b3:95:82:85
inphy0: <i82555 10/100 media interface> on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: <PCI to ISA bridge (vendor=3D1106 device=3D3147)> at device 17.0 on =
pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 8233 ATA133 controller> port 0xe400-0xe40f at device 17.1 on =
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
orm0: <Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcdfff,0xce000-0xcf7f=
f on isa0
fdc0: <NEC 72065B or clone> 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
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=3D0x300>
ad1: 1916MB <Maxtor 72004 AP> [3893/16/63] at ata0-slave WDMA2
acd0: CD-RW <PLEXTOR CD-R PX-W4012A> at ata0-master PIO4
Mounting root from ufs:/dev/da0s1a
da0 at asr0 bus 0 target 0 lun 0
da0: <ADAPTEC RAID-5 370L> Fixed Direct Access SCSI-2 device=20
da0: Tagged Queueing Enabled
da0: 343419MB (703322112 512 byte sectors: 255H 63S/T 43779C)
WARNING: / was not properly dismounted

Now, as I've stated before, this has been happening on
this machine periodically over the past several months. I have
absolutely no idea why, and I don't know if it was just a fluke
that it stayed up since December on a slightly older code base.
I'm not sure if this is FXP related, or UFS + soft-updates
related, or maybe even NFS related, since that is most of what
this machine does. I have no idea. Does anyone else have any
ideas?

- --=20
Mark Nipper e-contacts:
Computing and Information Services ni...@tamu.edu
Texas A&M University http://ops.tamu.edu/nipsy/
College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617
(979)575-3193 MSN: ni...@tamu.edu

- -----BEGIN GEEK CODE BLOCK-----
GG/IT d- s++:+ a-- C++$ UBL+++$ P--->+++ L+++$ E---
W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+
PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**)
- ------END GEEK CODE BLOCK------

- ---begin random quote of the moment---
"Give us this day our daily Faith, but deliver us, dear God, from
Belief."

-- Aldous Huxley, _Island_, 1962S
- ----end random quote of the moment----

------------------------------

Date: Thu, 6 Feb 2003 13:39:31 -0400 (AST)
From: "Marc G. Fournier" <scr...@hub.org>
Subject: Re: another crash with 4.7-STABLE

we're getting an almost daily crash here as well, but due to some changes
in ip_output, my netdump module is no longer working to get anything for
gdb :(

On Thu, 6 Feb 2003, Mark Nipper wrote:

> Well, I should have learned my lesson, but I didn't. I
> had a seemingly stable running kernel which was using code from
> CVS (using RELENG_4) from around Wed Dec 18 16:01:04 CST 2002
> until just a couple of days ago when I still hadn't seen the
> sporadic crashes which I'd been seeing.
>
> SO, I figured that whatever was wrong with versions prior
> to that had been fixed and I decided to update to the latest
> STABLE again, just for the hell of it. BIG MISTAKE. :(
>
> So, I was running STABLE from around Tue Feb 4 10:46:08
> CST 2003 for just about two days (1d21h12m2s to be exact) and
> oops, it crashed. Here's all the info:

------------------------------

Date: Thu, 6 Feb 2003 13:50:22 -0400 (AST)
From: "Marc G. Fournier" <scr...@hub.org>
Subject: ip_output args changed, added a struct inpcb ...

Darryl ...

They appear to have changed the args for ip_output, but am not sure what
I need to do to fix it in the netdump code :(

The new structure appears to be:

int ip_output(struct mbuf *,
struct mbuf *, struct route *, int, struct ip_moptions *,
struct inpcb *);

My guess is that I just need to put 0 in for ip_pcb ... ? but I
don't know enough about ip_output to do more then guess ...

Checking the diffs at:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.99.2.33&r2=1.99.2.34&only_with_tag=RELENG_4&f=h

The addition was made in 1.99.2.34 of the inpcb struct ...

- ---------- Forwarded message ----------
Date: Wed, 5 Feb 2003 23:54:15 -0400 (AST)
From: Marc G. Fournier <scr...@hub.org>
To: freebsd...@freebsd.org
Subject: ip_output args changed ... ?

Can't find a man page for it, so can someone tell me what I need to do to
get this fixed?

netdump_client.c: In function `netdump_output':
netdump_client.c:162: too few arguments to function `ip_output'
*** Error code 1

Stop in /root/netdump.
jupiter# grep ip_output *
netdump_client.c: error = ip_output(m, NULL, &ro, IP_ALLOWBROADCAST, 0);

Thanks ...

------------------------------

Date: Thu, 06 Feb 2003 10:26:22 -0800
From: Glenn Dawson <gl...@antimatter.net>
Subject: Re: wi0: wi_cmd: busy bit won't clear

Yes, I am using WEP. Forgot to mention that in my first email. Were you
able to find a workaround or a fix of some sort?

Here's what I have...

wi0: <Intersil Prism2.5> mem 0xd7801000-0xd7801fff irq 10 at device 9.0 on pci0
wi0: 802.11 address: 00:05:5d:f9:c2:3e
wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI)
wi0: Intersil Firmware: Primary 1.00.07, Station 1.03.06

- -Glenn

At 08:36 AM 2/6/03, you wrote:
>On Thursday 06 February 2003 08:13, Glenn Dawson wrote:
> > Is this a known problem with the DWL-520? Anyone else seen the same
> > thing?
> >
> > I can provide more info if needed.
>
> Are you using WEP? Something similar happened to me with this
> DWL-650 (The
>Prism2.5 version)
>
>wi0 at port 0x240-0x27f irq 11 slot 0 on pccard0
>wi0: 802.11 address: 00:05:5d:5c:24:01
>wi0: using RF:PRISM2.5 MAC:ISL3873
>wi0: Intersil Firmware: Primary 1.00.07, Station 1.03.05
>
>
>
>
> Borja.

------------------------------

Date: Thu, 06 Feb 2003 13:41:03 -0500
From: Chuck Swiger <ch...@codefab.com>
Subject: AHC/D debug options in GENERIC...?

Hi--

Is it intential that these be included in the GENERIC kernel:

# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.50 2002/12/30 19:04:31
rwatson Exp $
[ ... ]
options AHC_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~215k to driver.

...? I'm not suggesting they be disabled, per se; anyone tuning a
kernel can turn them off if they want to.

- -Chuck

------------------------------

Date: Thu, 06 Feb 2003 12:40:07 -0700
From: Scott Long <scott...@btc.adaptec.com>
Subject: Re: AHC/D debug options in GENERIC...?

Chuck Swiger wrote:

> Hi--
>
> Is it intential that these be included in the GENERIC kernel:
>
> # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.50 2002/12/30 19:04:31
> rwatson Exp $
> [ ... ]
> options AHC_REG_PRETTY_PRINT # Print register bitfields in debug
> # output. Adds ~128k to driver.
> options AHD_REG_PRETTY_PRINT # Print register bitfields in debug
> # output. Adds ~215k to driver.
>
> ...? I'm not suggesting they be disabled, per se; anyone tuning a
> kernel can turn them off if they want to.
>
> -Chuck
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message

They are in the GENERIC kernel but not on the install floppy kernel.
The reason they are on is to aid us in debugging problems for people
remotely. They cause no significant slowdown, just lots of information
when problems occur. The size impact of each is about 150k.

Scott

------------------------------

Date: 07 Feb 2003 04:12:13 +0800
From: sl...@taiwan.com
Subject: =?ISO-8859-1?B?pc6k36zdp7mz4SEhIS4uLi4u?=

<html>

<body>

祝您羊年
 
                   
一帆風順、二龍騰飛、三羊開泰、 
       
           
四季平安、五福臨門、六六大順、 
       
           
七星高照、八方來財、九九同心、 
       
           
十全十美，洋洋得意過好年 
 
 
              
           ****最有活力的-------<a href="http://amityslc.getU.to">小熊熊</a>

</body>

</html>

------------------------------

Date: Fri, 7 Feb 2003 04:01:22 +0800
From: hmb...@hknetmail.com
Subject: [none]

- -------------------------------------------------
HKNETMAIL.COM Free WEB MAIL Service by HKNET

------------------------------

Date: Thu, 06 Feb 2003 14:33:00 -0800
From: Darrell Anderson <dar...@google.com>
Subject: Re: ip_output args changed, added a struct inpcb ...

Yup, you can pass NULL as the new ip_output final argument, it's only
used for IPSEC.

- -Darrell

Marc G. Fournier wrote:
> Darryl ...
>
> They appear to have changed the args for ip_output, but am not sure what
> I need to do to fix it in the netdump code :(
>
> The new structure appears to be:
>
> int ip_output(struct mbuf *,
> struct mbuf *, struct route *, int, struct ip_moptions *,
> struct inpcb *);
>
> My guess is that I just need to put 0 in for ip_pcb ... ? but I
> don't know enough about ip_output to do more then guess ...
>
> Checking the diffs at:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.99.2.33&r2=1.99.2.34&only_with_tag=RELENG_4&f=h
>
> The addition was made in 1.99.2.34 of the inpcb struct ...
>
> ---------- Forwarded message ----------
> Date: Wed, 5 Feb 2003 23:54:15 -0400 (AST)
> From: Marc G. Fournier <scr...@hub.org>
> To: freebsd...@freebsd.org
> Subject: ip_output args changed ... ?
>
>
> Can't find a man page for it, so can someone tell me what I need to do to
> get this fixed?
>
> netdump_client.c: In function `netdump_output':
> netdump_client.c:162: too few arguments to function `ip_output'
> *** Error code 1
>
> Stop in /root/netdump.
> jupiter# grep ip_output *
> netdump_client.c: error = ip_output(m, NULL, &ro, IP_ALLOWBROADCAST, 0);
>
> Thanks ...
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>

------------------------------

Date: Thu, 6 Feb 2003 17:47:39 -0500
From: Don Bowman <d...@sandvine.com>
Subject: ahd1: PCI error interrupt

Has anyone else seen this error while coming up on a RELENG-4
system?

relevant pciconf output:
ahd0@pci3:2:0: class=0x010000 card=0x005f9005 chip=0x801f9005 rev=0x03
hdr=0x00
ahd1@pci3:2:1: class=0x010000 card=0x005f9005 chip=0x801f9005 rev=0x03
hdr=0x00

This is on a supermicro X5DPR 2x 2.8GHz XEON with an AIC 7802 SCSI.

This happened while the machine was coming up.

ahd1: PCI error Interrupt
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
ahd1: Dumping Card State at program address 0xe Mode 0x33
Card was paused
HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0]
DFFSTAT[0x30] SCSISIGI[0x0] SCSIPHASE[0x0] SCSIBUS[0x0]
LASTPHASE[0x1] SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x10]
SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] SSTAT0[0x0]
SSTAT1[0x8] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0]
SIMODE1[0xa4] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0]
LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0]

SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0x0 NEXTSCB 0x0
qinstart = 0 qinfifonext = 0
QINFIFO:
WAITING_TID_QUEUES:
Pending list:
Total 0
Kernel Free SCB list: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Sequencer Complete DMA-inprog list:
Sequencer Complete list:
Sequencer DMA-Up and Complete list:

ahd1: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0, LJSCB 0xff00
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
ahd1: FIFO1 Free, LONGJMP == 0x80ff, SCB 0x0, LJSCB 0xff00
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0
ahd1: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42
ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0
SIMODE0[0x6c]
CCSCBCTL[0x0]
ahd1: REG0 == 0xc169, SINDEX = 0x33, DINDEX = 0x0
ahd1: SCBPTR == 0x1ff, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x0
CDB ff 1 0 0 0 0
STACK: 0x8 0x7 0x6 0x5 0x4 0x3 0x2e 0xe
<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
ahd1: Signaled Target Abort

------------------------------

Date: Thu, 6 Feb 2003 17:51:21 -0500
From: Don Bowman <d...@sandvine.com>
Subject: RE: ahd1: PCI error interrupt

From: Don Bowman [mailto:d...@sandvine.com]
...
>
> This is on a supermicro X5DPR 2x 2.8GHz XEON with an AIC 7802 SCSI.

sorry, make that 7902:

ahd0: <Adaptec AIC7902 Ultra320 SCSI adapter> port
0x4000-0x40ff,0x4400-0x44ff mem 0xfc300000-0xfc301fff irq 22 at device 2.0
on pci3
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
ahd1: <Adaptec AIC7902 Ultra320 SCSI adapter> port
0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 23 at device 2.1
on pci3
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
ahd0: <Adaptec AIC7902 Ultra320 SCSI adapter> port
0x4000-0x40ff,0x4400-0x44ff mem 0xfc300000-0xfc301fff irq 22 at device 2.0
on pci3
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
ahd1: <Adaptec AIC7902 Ultra320 SCSI adapter> port
0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 23 at device 2.1
on pci3
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs

------------------------------

Date: Fri, 07 Feb 2003 11:19:35 +1100
From: Gregory Bond <g...@itga.com.au>
Subject: Re: wi0: wi_cmd: busy bit won't clear

> ad-hoc. After large amounts of traffic (such as copying a large file) on
> the wireless interface, it stops responding.

I have a DWL-520, in hostap mode, with WEP. I've not seen this problem ever,
but I've not put more than a few 10s of Mb through it at a time. How big is
"large" in your case? Sending or receiving? I'll give it a bit more of a
beating tonight and see if I get the same problem.

------------------------------

Date: Thu, 6 Feb 2003 18:48:10 -0500
From: "Ben Pfountz" <netp...@vt.edu>
Subject: SPAM: [Sender DNS] Re: wi_cmd: busy bit won't clear

Glenn,

I used the same card for a few weeks trying to figure out that problem. I
turned off wep the problem appeared to go away. Then I found that the
Belkin F5D6020 uses a prism chipset, and when I use this card I can use WEP
without any problems at all. My conclusion was that there is something a
little flaky with the DWL-520.

Ben

- ----- Original Message -----
From: "Glenn Dawson" <gl...@antimatter.net>
To: <freebsd...@FreeBSD.ORG>
Sent: Thursday, February 06, 2003 2:13 AM
Subject: wi0: wi_cmd: busy bit won't clear

> I have a D-Link DWL-520 in a box running -STABLE that's acting as a
> router. I recently switched to using it in hostap mode instead of
> ad-hoc. After large amounts of traffic (such as copying a large file) on
> the wireless interface, it stops responding. Traffic on the other two
> (wired) interfaces continues as normal. The only way I've been able to
get
> things working again is a reboot. The following error appears in
messages:
>
> wi0: wi_cmd: busy bit won't clear
>
> Is this a known problem with the DWL-520? Anyone else seen the same
thing?
>
> I can provide more info if needed.
>
> Any help would be much appreciated.
>
> -Glenn
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>
>

------------------------------

Date: Thu, 6 Feb 2003 18:48:10 -0500
From: "Ben Pfountz" <netp...@vt.edu>
Subject: SPAM: [Sender DNS] Re: wi_cmd: busy bit won't clear

Glenn,

Ben

- ----- Original Message -----
From: "Glenn Dawson" <gl...@antimatter.net>
To: <freebsd...@FreeBSD.ORG>
Sent: Thursday, February 06, 2003 2:13 AM
Subject: wi0: wi_cmd: busy bit won't clear

------------------------------

Date: Thu, 06 Feb 2003 16:36:07 -0800
From: Glenn Dawson <gl...@antimatter.net>
Subject: Re: wi0: wi_cmd: busy bit won't clear

Large in my case is ~400MB or so. I've noticed the problem when I've tried
to copy a CD image from the machine with the DWL-520 to another. I've also
seen it happen when I was streaming mp3's to a machine on the wireless
network. It would appear to only happen when sending, but I typically
don't move much data in the other direction.

- -Glenn

At 04:19 PM 2/6/03, Gregory Bond wrote:
> > ad-hoc. After large amounts of traffic (such as copying a large file) on
> > the wireless interface, it stops responding.
>
>I have a DWL-520, in hostap mode, with WEP. I've not seen this problem ever,
>but I've not put more than a few 10s of Mb through it at a time. How big is
>"large" in your case? Sending or receiving? I'll give it a bit more of a
>beating tonight and see if I get the same problem.
>
>
>
>To Unsubscribe: send mail to majo...@FreeBSD.org
>with "unsubscribe freebsd-stable" in the body of the message

------------------------------

Date: Fri, 07 Feb 2003 11:48:22 +1100
From: Gregory Bond <g...@itga.com.au>
Subject: Re: wi0: wi_cmd: busy bit won't clear

> Large in my case is ~400MB or so. I've noticed the problem when I've tried
> to copy a CD image from the machine with the DWL-520 to another. I've also
> seen it happen when I was streaming mp3's to a machine on the wireless
> network. It would appear to only happen when sending, but I typically
> don't move much data in the other direction.

Hmmm, OK, most of my large transfers are the other way (from the WinME client
into the BSD box with the 520 card. I'll try doing a large copy the other way
and see what happens.

------------------------------

Date: Thu, 6 Feb 2003 17:53:09 -0800
From: Cliff Skolnick <cl...@steam.com>
Subject: Re: wi0: wi_cmd: busy bit won't clear

I would suggest you both upgrade the firmware on your cards to 1.1.0 /
1.4.9 as it runs hostap mode the best. I had lots of strange problems,
especially with wep, without it.

Cheers,
Cliff

wi0: Intersil Firmware: Primary 1.01.00, Station 1.04.09

is what you want to see :)

On Thursday, Feb 6, 2003, at 10:26 US/Pacific, Glenn Dawson wrote:

> Yes, I am using WEP. Forgot to mention that in my first email. Were
> you able to find a workaround or a fix of some sort?
>
> Here's what I have...
>
> wi0: <Intersil Prism2.5> mem 0xd7801000-0xd7801fff irq 10 at device
> 9.0 on pci0
> wi0: 802.11 address: 00:05:5d:f9:c2:3e
> wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI)
> wi0: Intersil Firmware: Primary 1.00.07, Station 1.03.06
>
> -Glenn
>
> At 08:36 AM 2/6/03, you wrote:
>> On Thursday 06 February 2003 08:13, Glenn Dawson wrote:
>> > Is this a known problem with the DWL-520? Anyone else seen the same
>> > thing?
>> >
>> > I can provide more info if needed.
>>
>> Are you using WEP? Something similar happened to me with this
>> DWL-650 (The
>> Prism2.5 version)
>>
>> wi0 at port 0x240-0x27f irq 11 slot 0 on pccard0
>> wi0: 802.11 address: 00:05:5d:5c:24:01
>> wi0: using RF:PRISM2.5 MAC:ISL3873
>> wi0: Intersil Firmware: Primary 1.00.07, Station 1.03.05
>>
>>
>>
>>
>> Borja.
>
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>
- --
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- - Benjamin Franklin, 1759

------------------------------

Date: Fri, 7 Feb 2003 12:45:14 +1000
From: Paul Koch <paul...@statscout.com>
Subject: Invalid ps start time values for kernel processes ?

The ps output value for STARTED appears to be incorrect for
kernel started processes. I found this while writing a tiny ps
for our freebsd based network appliance. The start time returned
from /proc/{normal pid}/status (man procfs) appears to be in=20
UTC while the start time for a kernel process appears to be
localtime (or the other way round). This gave me wild values.
Is this correct behaviour ?

$ uname -a
FreeBSD speedy.statscout.com 4.7-RELEASE FreeBSD 4.7-RELEASE #0:=20
Tue Dec 17 08:22:00 EST 2002 ro...@speedy.statscout.com:/usr/src/sys/comp=
ile/BSD47 i386

$ date
Fri Feb 7 12:31:33 EST 2003

$ uptime
12:31PM up 3:56, 4 users, load averages: 0.15, 0.17, 0.09

My timezone is +10hours.

$ ps -aux
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 193 1.0 11.3 29936 14308 ?? Ss 8:35AM 2:56.69 /usr/X11R6=
/bin/XFree86 -auth /usr/X11R6/lib/X11/xdm/authdir/authfiles/A:0-vZLPV9
root 1 0.0 0.1 552 72 ?? ILs 6:35PM 0:00.01 /sbin/init =
- --
root 2 0.0 0.0 0 0 ?? DL 6:35PM 0:03.44 (pagedaemo=
n)
root 3 0.0 0.0 0 0 ?? DL 6:35PM 0:00.78 (vmdaemon)
root 4 0.0 0.0 0 0 ?? DL 6:35PM 0:00.10 (bufdaemon=
)
root 5 0.0 0.0 0 0 ?? DL 6:35PM 0:00.09 (vnlru)
root 6 0.0 0.0 0 0 ?? DL 6:35PM 0:01.34 (syncer)
root 23 0.0 0.0 212 0 ?? IWs - 0:00.00 adjkerntz -=
i
root 71 0.0 0.2 944 248 ?? Ss 8:35AM 0:00.08 /usr/sbin/s=
yslogd -s
daemon 74 0.0 0.0 944 0 ?? IWs - 0:00.00 /usr/sbin/p=
ortmap
root 76 0.0 0.0 500 0 ?? IWs - 0:00.00 mountd -r
root 79 0.0 0.0 368 0 ?? IWs - 0:00.00 nfsd: maste=
r (nfsd)
root 81 0.0 0.0 360 0 ?? IW - 0:00.00 nfsd: serve=
r (nfsd)
root 82 0.0 0.0 360 0 ?? IW - 0:00.00 nfsd: serve=
r (nfsd)
root 83 0.0 0.0 360 0 ?? IW - 0:00.00 nfsd: serve=
r (nfsd)
root 84 0.0 0.0 360 0 ?? IW - 0:00.00 nfsd: serve=
r (nfsd)
root 86 0.0 0.0 263084 0 ?? IWs - 0:00.00 rpc.statd
root 91 0.0 0.0 212 0 ?? IW - 0:00.00 nfsiod -n 4
root 92 0.0 0.0 212 0 ?? IW - 0:00.00 nfsiod -n 4
root 93 0.0 0.0 212 0 ?? IW - 0:00.00 nfsiod -n 4
root 94 0.0 0.0 212 0 ?? IW - 0:00.00 nfsiod -n 4
root 100 0.0 0.0 1076 0 ?? IWs - 0:00.00 /usr/sbin/i=
netd -wW
root 102 0.0 0.2 996 192 ?? Is 8:35AM 0:00.05 /usr/sbin/c=
ron
root 105 0.0 0.0 968 0 ?? IWs - 0:00.00 /usr/sbin/l=
pd
root 107 0.0 0.1 968 100 ?? S 8:35AM 0:00.03 /usr/sbin/l=
pd
root 108 0.0 0.0 2740 0 ?? IWs - 0:00.00 /usr/sbin/s=
shd
root 110 0.0 0.1 916 88 ?? Ss 8:35AM 0:00.02 /usr/sbin/u=
sbd
root 113 0.0 0.4 2660 460 ?? Ss 8:35AM 0:00.51 sendmail: a=
ccepting connections (sendmail)
smmsp 116 0.0 0.4 2660 440 ?? Is 8:35AM 0:00.01 sendmail: Q=
ueue runner@00:30:00 for /var/spool/clientmqueue (sendmail)
root 133 0.0 0.1 912 72 ?? Is 8:35AM 0:03.49 moused -p /=
dev/psm0 -t auto
root 146 0.0 0.2 2128 220 ?? Ss 8:35AM 0:00.46 /usr/local/=
sbin/httpd
www 162 0.0 0.0 2128 0 ?? IW - 0:00.00 /usr/local/=
sbin/httpd
www 163 0.0 0.0 2152 0 ?? IW - 0:00.00 /usr/local/=
sbin/httpd
www 164 0.0 0.0 2152 0 ?? IW - 0:00.00 /usr/local/=
sbin/httpd
www 165 0.0 0.0 2152 0 ?? IW - 0:00.00 /usr/local/=
sbin/httpd
www 166 0.0 0.0 2188 0 ?? IW - 0:00.00 /usr/local/=
sbin/httpd
root 179 0.0 0.0 3408 0 con- IW+ - 0:00.00 /usr/local/=
sbin/snmpd
root 182 0.0 0.0 948 0 v0 IWs+ - 0:00.00 /usr/libexe=
c/getty Pc ttyv0
root 183 0.0 0.0 948 0 v1 IWs+ - 0:00.00 /usr/libexe=
c/getty Pc ttyv1
root 184 0.0 0.0 948 0 v2 IWs+ - 0:00.00 /usr/libexe=
c/getty Pc ttyv2
root 185 0.0 0.0 948 0 v3 IWs+ - 0:00.00 /usr/libexe=
c/getty Pc ttyv3
root 186 0.0 0.0 948 0 v4 IWs+ - 0:00.00 /usr/libexe=
c/getty Pc ttyv4
etc......

Paul Koch (CTO Statscout Pty Ltd)
Email: paul...@statscout.com
Phone: +61 7 32117115 Fax: +61 7 32117829
7th Floor, 300 Adelaide St, Brisbane, Australia

------------------------------

Date: Fri, 7 Feb 2003 14:47:26 +1100 (EST)
From: Andrew <and...@ugh.net.au>
Subject: Re: wi0: wi_cmd: busy bit won't clear

On Wed, 5 Feb 2003, Glenn Dawson wrote:

> wi0: wi_cmd: busy bit won't clear
>
> Is this a known problem with the DWL-520? Anyone else seen the same thing?

I get the same problem with a Linksys WMP11. I tried upgrading the
firmware to see if that helped (had to put the card in a windows box to do
it) and now it doesn't seem to work at all.

Andrew

------------------------------

Date: Fri, 7 Feb 2003 14:48:04 +1100 (EST)
From: Andrew <and...@ugh.net.au>
Subject: Re: wi0: wi_cmd: busy bit won't clear

On Thu, 6 Feb 2003, Glenn Dawson wrote:

> Yes, I am using WEP. Forgot to mention that in my first email. Were you

I wasn't using WEP so that might not be related.

Andrew

------------------------------

Date: Thu, 6 Feb 2003 23:49:18 -0600
From: Mark Nipper <ni...@tamu.edu>
Subject: OpenSSH_3.5p1 FreeBSD-20030201 crash

In trying to make my FreeBSD NFS server crash by running
three tcpdump's and one trafshow via SSH from a Linux machine, I
received and interesting error and crash on one of the tcpdump
SSH sessions:
- ---
corrupted mac on input

Looking around, I noticed only a handful of reports on
this. I have an fxp interface:
- ---
fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xe000-0xe03f mem 0xed000000-0xed01ffff,0xed020000-0xed020fff irq 11 at device 11.0 on pci0

and have been seeing other strange crashes as I've mentioned in a
couple of previous posts. I do not have DEVICE_POLLING turned on
currently, but I think I'm going to enable it along with bumping
up my HZ value, just to see if that changes anything...

Anyway, any ideas on the SSH error?

- --
Mark Nipper e-contacts:
Computing and Information Services ni...@tamu.edu
Texas A&M University http://ops.tamu.edu/nipsy/
College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617
(979)575-3193 MSN: ni...@tamu.edu

- ---begin random quote of the moment---
If you're not on somebody's shit list, you're not doing anything
worthwhile.
- ----end random quote of the moment----

------------------------------

Date: Fri, 7 Feb 2003 02:02:14 -0500
From: Chris BeHanna <beh...@zbzoom.net>
Subject: mpd 3.11 problems?

Is anyone else seeing problems using mpd-3.11 to do PPTP to a
Windows RAS box?

I just had the frustrating experience of having my configuration
work with 3.10, upgrade to 3.11 and the tunnel endpoints get the
expected addresses, but cannot be pinged and no packets flow,
downgrade back to 3.10, and everything works again.

- --
Chris BeHanna
Software Engineer (Remove "bogus" before responding.)
beh...@bogus.zbzoom.net
Turning coffee into software since 1990.

------------------------------

Date: Fri, 07 Feb 2003 08:56:02 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Problems with pam_ssh(8) and ssh-agent(1) after the OpenSSH upgrade

As some of you have already noticed and reported, ssh-agent doesn't
work quite right when spawned by pam_ssh after the OpenSSH upgrade
earlier this week. This is caused by two factors. The first factor
is that ssh-agent has become quite pedantic about its operating
conditions, in an effort to prevent potential security problems. The
second factor is that the credential manipulations pam_ssh does before
spawning the agent are slightly wrong - not sufficiently wrong to pose
a serious threat, but sufficiently wrong to make ssh-agent suspicious.

In addition to that, there seems to be a problem with the credential
manipulation functions I wrote for OpenPAM (which are also used by
pam_ssh in -STABLE) which would cause pam_ssh to fail when invoked by
a privsep-enabled sshd. This doesn't seem to be much of a problem as
few or no users have pam_ssh in their sshd policy (it doesn't make
much sense, does it?).

I knew about the first problem before I upgraded OpenSSH in -STABLE,
because it had been reported by -CURRENT users and discussed on one of
the OpenSSH developer mailing lists. I discovered the second problem
while trying out potential workarounds for the first one. I am
working on resolving both issues, and hope to have a solution ready
during the weekend. I would also like to apologize for the
inconvenience caused by my forgetfulness.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 7 Feb 2003 14:49:40 +0100 (CET)
From: Oliver Fromme <ol...@secnetix.de>
Subject: Re: Invalid ps start time values for kernel processes ?

Paul Koch <paul...@statscout.com> wrote:
> The ps output value for STARTED appears to be incorrect for
> kernel started processes. I found this while writing a tiny ps
> for our freebsd based network appliance. The start time returned
> from /proc/{normal pid}/status (man procfs) appears to be in
> UTC while the start time for a kernel process appears to be
> localtime (or the other way round). This gave me wild values.
> Is this correct behaviour ?

Is your CMOS clock running with local time, rather than UTC?
(i.e. does the file /etc/wall_cmos_clock exist?)

In that case, the kernel will start up with the wrong time
information, because it doesn't know the timezone you're in
(the kernel always uses UTC internally). This information
is corrected by the adjkerntz program in the early stages
of the boot process.

However, the kernel processes start before that correction
happens. If you were living east of Greenwich (i.e. positive
timezone offset), the start time values would even be in the
future.

If FreeBSD is the only operating system on that machine,
I suggest that you run the CMOS clock with UTC, avoiding the
problem alltogether. Of course, you can also just ignore
the wrong start values. They should not cause any harm.

I don't think there is an easy way to fix the problem.

Regards
Oliver

- --
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 Mchen
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"All that we see or seem is just a dream within a dream" (E. A. Poe)

------------------------------

Date: Fri, 07 Feb 2003 15:49:24 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: Problems with pam_ssh(8) and ssh-agent(1) after the OpenSSH upgrade

Dag-Erling Smorgrav <d...@ofug.org> writes:
> As some of you have already noticed and reported, ssh-agent doesn't
> work quite right when spawned by pam_ssh after the OpenSSH upgrade
> earlier this week.

Could somebody experiencing this problem please test the following
patch:

Index: ssh-agent.c
===================================================================
RCS file: /home/ncvs/src/crypto/openssh/ssh-agent.c,v
retrieving revision 1.16
diff -u -u -r1.16 ssh-agent.c
- --- ssh-agent.c 29 Oct 2002 10:16:02 -0000 1.16
+++ ssh-agent.c 7 Feb 2003 07:09:47 -0000
@@ -955,6 +955,7 @@
/* drop */
setegid(getgid());
setgid(getgid());
+ setuid(geteuid());

SSLeay_add_all_algorithms();

After applying it, rebuild and reinstall ssh-agent as follows:

# cd /usr/src/secure/usr.bin/ssh-agent
# make && make install

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 07 Feb 2003 15:55:40 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

Mark Nipper <ni...@tamu.edu> writes:
> Anyway, any ideas on the SSH error?

Sure, if you tell me what the error is.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 7 Feb 2003 10:13:43 -0600
From: Mark Nipper <ni...@tamu.edu>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

On Fri, Feb 07, 2003 at 04:36:44PM +0100, Dag-Erling Smorgrav wrote:
> Mark Nipper <ni...@tamu.edu> writes:
> > The error was:
> > ---
> > corrupted mac on input
> >
> > as I said in my original post.
>
> You didn't say anything about what program prints the error message,
> or under what conditions. Neither did you explain what you meant by
> "crash", which I normally take to mean "the machine rebooted". I also
> don't understand what your brand of network interface has to do with
> any of this.
>
> To summarize, give more details and take care not to mix up unrelated
> matters.

Well, the error was nothing more than what I've already
said, and this appeared as the last bit of output in an ssh
session to another host, afterwards I only had my local prompt.
I was running tcpdump at the time on the remote side, so it was a
pretty active connection. Frankly, I'm not sure what the effect
this has when running a traffic analysis of any kind remotely,
but obviously it generates more traffic, which was the whole
reason I was doing it in the first place!

I mention the fxp interface, because people have
mentioned some weird crashes/reboots recently on the list and
I've been experiencing them myself on the remote machine to which
the ssh session died in the first place. The post of it on this
list had mentioned heavy use of tcpdump and trafshow, just
anything to put the card in promiscuous mode. I don't even
really have any hard data to think it's related, but I thought
I'd mention it at the very lest.

Searching deja.com, I found a few scant references to the
"corrupted mac" error and OpenSSH, but it all seemed to be
~3.[01]" era information for OpenSSH and certainly nothing as
recent as OpenSSH-3.5p1.

So, while I apologize for the lack of real data, it
doesn't seem to be a common problem, and I'm not entirely sure
that the problems are in fact, unrelated. I'm beginning to think
my hardware just needs to be thrown out the window and replaced
in full.

- ---begin random quote of the moment---
"Linux does not solve all the problems. But we are working on it."
-- Alan Cox
- ----end random quote of the moment----

------------------------------

Date: Fri, 7 Feb 2003 10:37:14 -0600
From: Dave Uhring <duh...@charter.net>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

On Friday 07 February 2003 08:55 am, Dag-Erling Smorgrav wrote:
> Mark Nipper <ni...@tamu.edu> writes:
> > Anyway, any ideas on the SSH error?
>
> Sure, if you tell me what the error is.

Before I replaced the binaries with those from the openssh-3.5p1 package and
disabled PAM this was what my machine reported:

Feb 6 06:59:43 willy sshd[139]: pam_start: malloc failed for pam_conv
Feb 6 06:59:43 willy sshd[139]: fatal: PAM: initialisation failed

------------------------------

Date: Fri, 7 Feb 2003 10:52:29 +0000
From: synkrat <syn...@midsouth.rr.com>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

On Fri February 7 2003 04:37 pm, Dave Uhring wrote:
> On Friday 07 February 2003 08:55 am, Dag-Erling Smorgrav wrote:
> > Mark Nipper <ni...@tamu.edu> writes:
> > > Anyway, any ideas on the SSH error?
> >
> > Sure, if you tell me what the error is.
>
> Before I replaced the binaries with those from the openssh-3.5p1 package
> and disabled PAM this was what my machine reported:
>
> Feb 6 06:59:43 willy sshd[139]: pam_start: malloc failed for pam_conv
> Feb 6 06:59:43 willy sshd[139]: fatal: PAM: initialisation failed
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message

Your troubles can be cured by updating src and rebuilding openssh.

[freebsd] / src / crypto / openssh
Revision 1.5 / (download) - annotate - [select for diffs], Fri Jan 31 11:08:07
2003 UTC (7 days, 5 hours ago) by des
Branch: MAIN
CVS Tags: HEAD
Changes since 1.4: +19 -0 lines
Diff to previous 1.4 (colored)

Fix keyboard-interactive authentication for ssh1. The problem was twofold:

- The PAM kbdint device sometimes doesn't know authentication succeeded
until you re-query it. The ssh1 kbdint code would never re-query the
device, so authentication would always fail. This patch has been
submitted to the OpenSSH developers.

- The monitor code for PAM sometimes forgot to tell the monitor that
authentication had succeeded. This caused the monitor to veto the
privsep child's decision to allow the connection.

These patches have been tested with OpenSSH clients on -STABLE, NetBSD and
Linux, and with ssh.com's ssh1 on Solaris.