Re: ata(4) -STABLE subsystem and tags MFC
It seems Dmitry Morozovsky wrote: Hello there Soren, any chances patch for ata subsystem at date: 2002/04/18 19:11:45; that fixes tagged support for ata(4) will be MFC'd before 4.6-R? If you mean the patch that went into -current it doesn't apply to the -stable branch at all, it fixed a problem introduced by the busdma integration, not the problem that apparently hit some on -stable. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvs commit: ports/mail/mutt-devel Makefile
On Sun, May 05, 2002 at 03:31:47PM -0400, Andy Sparrow wrote: Both of which are specifically stated to be incorrect (with an explanation why) by the maintainer of XFree86 xterm on his web page. XFree86's 'xterm' is a color xterm, and has been for years. We don't ship their termcap entry. Substituting the XFree86 termcap/terminfo entries for ours apparently fixes the currently broken behaviour. Yes, but other people does not like some features of the xterm termcap entry supplied by XFree86. Other OSen do not have xterm-color, though (as has already been mentioned, Solaris), so this breaks as soon as you ssh to one of these remote machines. As someone who runs Solaris servers from a FreeBSD desktop I do this a lot. What he said :) Also, some OS's have an entry for 'xterm-color' that is NOT the XFree86 xterm, but an obsolete xterm variant, and this will also break. And I absolutely agree. In fact we also have Solaris and Irix machines, which I hacked (adding a xterm-color entry, or redefining TERM in the session startup scripts). What I wanted to say is that defining termName in XTerm-color is *coherent* with FreeBSD having two distinct termcap xterm entries: mono and color. However, I also think that having those two entries is *bad*. IMHO, the xterm and xterm-color entries should be merged in only one xterm supporting color. Cheers, JMA -- ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** Beware of Programmers who carry screwdrivers -- Leonard Brandwein ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ata(4) -STABLE subsystem and tags MFC
Hi again, On Mon, 6 May 2002, Søren Schmidt wrote: SS any chances patch for ata subsystem at SS SS date: 2002/04/18 19:11:45; SS SS that fixes tagged support for ata(4) will be MFC'd before 4.6-R? SS SS If you mean the patch that went into -current it doesn't apply to SS the -stable branch at all, it fixed a problem introduced by the SS busdma integration, not the problem that apparently hit some on -stable. Well then it's another problem in -stable, and currently tagged ata is not workable in all our -stable environments with IBM disks :( Machines do not crash, but constantly reinitialising ATA subsystem just at trying to boot first FS at tagged disk. What info do you need so we can try to fix this? Thanks. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
panic: ffs_vfree: freeing free inode
One of my 4.5-STABLE servers crashed today with this msg:
panic: ffs_vfree: freeing free inode
I have the kernel.debug and the dump. I don't know how to debug
ffs stuff but I I am happy if someone instructs me what to do.
Since the filesystems are mounted with softupdates it might be
a bug in the softupdates code. The kernel (and userland) where
compiled Thu Mar 28 14:37:35 CET 2002. I can't remember any
commits to the fs code so I assume the problem is in 4.6-PRERELEASE
as well.
This is what I got so far:
root@server:/var/crashgdb -k /usr/obj/src/src-4/sys/server/kernel.debug vmcore.10
GNU gdb 4.18
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 conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD at phsyical address 0x00303000
initial pcb at physical address 0x00282ee0
panicstr: ffs_vfree: freeing free inode
panic messages:
---
panic: ffs_vfree: freeing free inode
syncing disks... 31 5 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
giving up on 1 buffers
Uptime: 18d6h24m37s
dumping to dev #da/9, offset 276456
dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492
491 490 489 488 487 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 431 430 429
428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 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 356 355 354 353 352 351 350 349 348 347 346 345
344 343 342 341 340 339 338 337 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
281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 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 206 205 204 203 202 201 200 199 198
197 196 195 194 193 192 191 190 189 188 187 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 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114
113 112 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
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 1 0 [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abor
---
#0 dumpsys () at /src/src-4/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /src/src-4/sys/kern/kern_shutdown.c:487
#1 0xc0161443 in boot (howto=256) at /src/src-4/sys/kern/kern_shutdown.c:316
#2 0xc0161868 in poweroff_wait (junk=0xc0255591, howto=0)
at /src/src-4/sys/kern/kern_shutdown.c:595
#3 0xc01f0781 in ffs_freefile (pvp=0xd5321e64, ino=3, mode=17407)
at /src/src-4/sys/ufs/ffs/ffs_alloc.c:1611
#4 0xc01f58a4 in handle_workitem_freefile (freefile=0xc49793a0)
at /src/src-4/sys/ufs/ffs/ffs_softdep.c:2913
#5 0xc01f2e43 in process_worklist_item (matchmnt=0x0, flags=0)
at /src/src-4/sys/ufs/ffs/ffs_softdep.c:737
#6 0xc01f2cae in softdep_process_worklist (matchmnt=0x0)
at /src/src-4/sys/ufs/ffs/ffs_softdep.c:622
#7 0xc018e72f in sched_sync () at /src/src-4/sys/kern/vfs_subr.c:1177
(kgdb) up 3
#3 0xc01f0781 in ffs_freefile (pvp=0xd5321e64, ino=3, mode=17407)
at /src/src-4/sys/ufs/ffs/ffs_alloc.c:1611
1611panic(ffs_vfree: freeing free inode);
(kgdb)
Now I wanted to look at fs-fs_fsmnt and found strange stuff in there.
Here is the complete fs struct:
(kgdb) print *fs
$1 = {fs_firstfield = 1601398374, fs_unused_1 = 1701996150, fs_sblkno = 1713388133,
fs_cblkno = 1768252786, fs_iblkno = 1713399662, fs_dblkno = 543516018, fs_cgoffset =
1685024361,
fs_cgmask = 101, fs_time = 0, fs_size = 0, fs_dsize = 0, fs_ncg = 1929379840,
fs_bsize = 1953653108, fs_fsize = 622869792, fs_frag = 1814047844, fs_minfree =
1025535589,
fs_rotdelay = 744760608, fs_rps = 544433696, fs_bmask =
Re: ata(4) -STABLE subsystem and tags MFC
It seems Dmitry Morozovsky wrote: SS If you mean the patch that went into -current it doesn't apply to SS the -stable branch at all, it fixed a problem introduced by the SS busdma integration, not the problem that apparently hit some on -stable. Well then it's another problem in -stable, and currently tagged ata is not workable in all our -stable environments with IBM disks :( Machines do not crash, but constantly reinitialising ATA subsystem just at trying to boot first FS at tagged disk. What info do you need so we can try to fix this? I need to be able to reproduce it here in my lab, and so far I havn't had any luck with that. There also doesn't seem to be any easy to find denominator between the systems that fail... The problem is probably timing related, perhaps I have gotten something a wee bit out of spec, but not enough for all systems to fail... Anyhow this is a bitch to debug -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ata(4) -STABLE subsystem and tags MFC
On Mon, 6 May 2002, Søren Schmidt wrote: SS Well then it's another problem in -stable, and currently tagged ata is not SS workable in all our -stable environments with IBM disks :( Machines do not SS crash, but constantly reinitialising ATA subsystem just at trying to boot SS first FS at tagged disk. SS SS What info do you need so we can try to fix this? SS SS I need to be able to reproduce it here in my lab, and so far I havn't SS had any luck with that. There also doesn't seem to be any easy to find SS denominator between the systems that fail... SS SS The problem is probably timing related, perhaps I have gotten something SS a wee bit out of spec, but not enough for all systems to fail... SS SS Anyhow this is a bitch to debug Yeah, I see. By the way, I have a test machine handy, and also space GXP disc, so I'm going to build testcase. It's K6/2-450 at TX motherboard. What info do I need to send? (possibly, we should move the discussion of the precise details to private mail, yeah?) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ipfilter problem
Jens Rehsack([EMAIL PROTECTED])@2002.05.06 15:04:14 +: Karsten W. Rohrbach wrote: pass in quick on isp0 proto tcp from any to any port = 80 flags S/SA keep state # we want state added when establishing a # session, not for every tcp packet that passes # this rule If you read your own statement above you can cut the flags, because all dynamic rules added quick before this rule/line, so this rule is never parsed for any already matched ... valid point, my reasoning was wrong (worse: it hurts so bad, that i wonder why nobody else intervened ;-) the reasoning about why flags S/SA boils down to the point that no out-of-session packet should be allowed to create a state. session establishment is restricted to SYN/SYN+ACK packets, nothing more. IIRC, the state will just hang there until it times out, but it will be there and use a slot in the state table; ipfilter will not pass a matching packet because of the incomplete session state which is tracked in the state table, anyway. regards, /k -- Experience is a teacher that gives the examination first and the lesson afterwards. WebMonster Community Project -- Next Generation Networks GmbH -- All on BSD http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x msg45004/pgp0.pgp Description: PGP signature
fxp0: SCB timeout
I'm seeing these messages scroll past on the console quite rapidly: fxp0: device timeout fxp0: DMA timeout fxp0: DMA timeout fxp0: SCB timeout: 0x10 0x0 0x80 0x0 I searched the mailing list archive and came up with some people having the same problem, but no definitive answers. The hardware is a Dell 1550 with dual onboard Intel NIC's, running 4.5-STABLE (cvsup'd as of two weeks ago). There are four other identical servers on the same switch that are not having this problem, this occurs only on this one host. After are reboot the box is fine for an hour or so before it starts to die again. Any suggestions? Thanks, Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: fxp0: SCB timeout
I also have a Dell PowerEdge 1550 with 4.5-STABLE and had the same SCB timeout problem with the fxp driver. I never found much definitive info, but I did hear one suggestion that this was somehow related to advanced power management. I rebuilt a kernel without APM by removing the line: device apm0at nexus?... I have not had any problems with this since then, but I would only have the problem in periodic storms anyway. Thus there is no way for me to be sure if it is just coincidence that I haven't experience the problem since then. I would appreciate it if anyone else could/would shed some more light on this issue. It seems those of us with ServerWorks chipset motherboards and versions of Intel Pro cards w/ the fxp driver have this issue. Dmesg below: [...snip...] pcib0: ServerWorks host to PCI bridge on motherboard pci0: PCI bus on pcib0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xecc0-0xecff mem 0xfe10-0xfe1f ,0xfe2ff000-0xfe2f irq 11 at device 1.0 on pci0 [...snip...] On Monday, May 06, 2002, Paul Dlug wrote: I'm seeing these messages scroll past on the console quite rapidly: fxp0: device timeout fxp0: DMA timeout fxp0: DMA timeout fxp0: SCB timeout: 0x10 0x0 0x80 0x0 I searched the mailing list archive and came up with some people having the same problem, but no definitive answers. The hardware is a Dell 1550 with dual onboard Intel NIC's, running 4.5-STABLE (cvsup'd as of two weeks ago). There are four other identical servers on the same switch that are not having this problem, this occurs only on this one host. After are reboot the box is fine for an hour or so before it starts to die again. Any suggestions? Thanks, Paul Kendall Gifford http://kendall.jedis.com [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: BIND in -stable
matusita Anybody knows when 8.3.2 is out? I've contacted ISC directly, and found that 8.3.2 will be released real soon (yes, real soon). If it doesn't released before May/11/2002, they'll release 8.3.1p1 for bugfix-release of 8.3.1. Any committers import new BIND code when released? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Unable to alias IP's in 4.5
It seems from FreeBSD version 4.5 on I am unable to alias IP addresses to a NIC card if the IP I am trying to alias has the same netmask as the previously bound IP. I get nothing but a file exists error from ifconfig. I have been doing this since 3.4 so Im wondering what has changed. -- The fact that no one understands you doesn't mean you're an artist. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: fxp0: SCB timeout
I have apm disabled in the kernel already. I have the same ServerWorks chipset you mentioned. On Monday 06 May 2002 12:59 pm, Kendall Gifford wrote: I also have a Dell PowerEdge 1550 with 4.5-STABLE and had the same SCB timeout problem with the fxp driver. I never found much definitive info, but I did hear one suggestion that this was somehow related to advanced power management. I rebuilt a kernel without APM by removing the line: deviceapm0at nexus?... I have not had any problems with this since then, but I would only have the problem in periodic storms anyway. Thus there is no way for me to be sure if it is just coincidence that I haven't experience the problem since then. I would appreciate it if anyone else could/would shed some more light on this issue. It seems those of us with ServerWorks chipset motherboards and versions of Intel Pro cards w/ the fxp driver have this issue. Dmesg below: [...snip...] pcib0: ServerWorks host to PCI bridge on motherboard pci0: PCI bus on pcib0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xecc0-0xecff mem 0xfe10-0xfe1f ,0xfe2ff000-0xfe2f irq 11 at device 1.0 on pci0 [...snip...] On Monday, May 06, 2002, Paul Dlug wrote: I'm seeing these messages scroll past on the console quite rapidly: fxp0: device timeout fxp0: DMA timeout fxp0: DMA timeout fxp0: SCB timeout: 0x10 0x0 0x80 0x0 I searched the mailing list archive and came up with some people having the same problem, but no definitive answers. The hardware is a Dell 1550 with dual onboard Intel NIC's, running 4.5-STABLE (cvsup'd as of two weeks ago). There are four other identical servers on the same switch that are not having this problem, this occurs only on this one host. After are reboot the box is fine for an hour or so before it starts to die again. Any suggestions? Thanks, Paul Kendall Gifford http://kendall.jedis.com [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Unable to alias IP's in 4.5
On Mon, May 06, 2002 at 12:43:38PM -0500, Erich Zigler wrote: It seems from FreeBSD version 4.5 on I am unable to alias IP addresses to a NIC card if the IP I am trying to alias has the same netmask as the previously bound IP. I get nothing but a file exists error from ifconfig. I have been doing this since 3.4 so Im wondering what has changed. Possibly the change is in the code that should have been keeping you from doing that all along. That's certainly the case if the alias IP is in the same network as the original, non-alias IP. -- Mike Andrews [EMAIL PROTECTED] Tired old sysadmin since 1964 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
