Re: Problem with IBM Netfinity 5000 Server
Sorry for sending you all the messages from /var/log/messages, here is dmesg as the NIC at 5th PCI slot, Sorry for I cannot got dmesg as the NIC at 4th PCI slot, server reboot and I lost every things Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Wed Feb 23 13:56:44 CST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/www Calibrating clock(s) ... TSC clock: 498602083 Hz, i8254 clock: 1193024 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 498670656 Hz CPU: Pentium III/Pentium III Xeon (498.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 536854528 (524272K bytes) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0031c000 - 0x1fff3fff, 533561344 bytes (130264 pages) avail memory = 517894144 (505756K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fd5d0 bios32: Entry = 0xfd5e1 (c00fd5e1) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xd61c pnpbios: Found PnP BIOS data at 0xc00fde90 pnpbios: Entry = f:497d Rev = 1.0 Other BIOS signatures found: ACPI: 000fdec0 Preloaded elf kernel "kernel" at 0xc0303000. Pentium Pro MTRR support enabled Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x0070 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00071166) npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00071166) pcib0: Host to PCI bridge on motherboard found- vendor=0x1166, dev=0x0007, revid=0x04 class=06-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base , size 0 found- vendor=0x1166, dev=0x0005, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x1229, revid=0x05 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base febff000, size 12 map[14]: type 1, range 32, base 2000, size 5 map[18]: type 1, range 32, base fea0, size 20 found- vendor=0x9004, dev=0x7895, revid=0x04 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=15 map[10]: type 1, range 32, base 2200, size 8 map[14]: type 1, range 32, base febfe000, size 12 found- vendor=0x9004, dev=0x7895, revid=0x04 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=b, irq=10 map[10]: type 1, range 32, base 2300, size 8 map[14]: type 1, range 32, base febfd000, size 12 found- vendor=0x1022, dev=0x2000, revid=0x36 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base 2020, size 5 map[14]: type 1, range 32, base febfcc00, size 5 found- vendor=0x5333, dev=0x8901, revid=0x16 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base f800, size 26 found- vendor=0x1166, dev=0x0200, revid=0x4d class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x1166, dev=0x0210, revid=0x4a class=01-01-ea, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=14 map[10]: type 1, range 32, base 01f0, size 3 map[14]: type 1, range 32, base 03f4, size 2 map[18]: type 1, range 32, base 0010, size 3 map[1c]: type 1, range 32, base , size 2 map[20]: type 1, range 32, base ffa0, size 4 found- vendor=0x1166, dev=0x0220, revid=0x04 class=0c-03-10, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base ff70, size 12 pci0: PCI bus on pcib0 fxp0: Intel EtherExpress Pro 10/100B Ethernet port 0x2000-0x201f mem 0xfea0-0xfeaf,0xfebff000-0xfebf irq 11 at device 1.0 on pci0 fxp0: Ethernet address 00:04:ac:45:75:fc bpf: fxp0 attached ahc0: Adaptec aic7895 Ultra SCSI adapter port 0x2200-0x22ff mem 0xfebfe000-0xfebfefff irq 15 at device 6.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Low byte termination Enabled ahc0: High byte
Re: Panic (pmap)
-On [2223 10:01], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote:
And I may welcome panic #6 here.
db trace
pmap_remove_all(5a3e000,c061ab70,0,c0230ac0,d62a2f8c) at
pmap_remove_all+0x40
pmap_page_protect(5a3e000,0) at pmap_page_protect+0xde
vm_pageout_page_stats(0) at vm_pageout_page_stats+0x15e
vm_pageout(0) at vm_pageout+0x1fb
fork_trampoline() at fork_trampoline+0x8
[root@tyr] (1) # cd /var/crash/
/var/crash
[root@tyr] (2) # gdb -k /kernel.debug vmcore.2
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 2625536
initial pcb at 21c9e0
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01cdefc
stack pointer = 0x10:0xd62a2f44
frame pointer = 0x10:0xd62a2f50
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (pagedaemon)
interrupt mask = net bio cam
panic: from debugger
panic: from debugger
Uptime: 11h59m1s
amrd0: still open, can't shutdown
dumping to dev #da/0x20001, offset 524312
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 1 0
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
#1 0xc0143d61 in panic (fmt=0xc01e27f4 "from debugger")
at ../../kern/kern_shutdown.c:554
#2 0xc01244e1 in db_panic (addr=-1071849732, have_addr=0, count=-1,
modif=0xd62a2db0 "") at ../../ddb/db_command.c:433
#3 0xc0124481 in db_command (last_cmdp=0xc02042fc, cmd_table=0xc020415c,
aux_cmd_tablep=0xc021905c) at ../../ddb/db_command.c:333
#4 0xc0124546 in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc012665f in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xc01c4ec5 in kdb_trap (type=12, code=0, regs=0xd62a2f04)
at ../../i386/i386/db_interface.c:158
#7 0xc01d0c38 in trap_fatal (frame=0xd62a2f04, eva=0)
at ../../i386/i386/trap.c:919
#8 0xc01d0911 in trap_pfault (frame=0xd62a2f04, usermode=0, eva=0)
at ../../i386/i386/trap.c:817
#9 0xc01d04c3 in trap (frame={tf_fs = -701890544, tf_es = -1071906800,
tf_ds = 16, tf_edi = 0, tf_esi = -1061788720, tf_ebp = -701878448,
tf_isp = -701878480, tf_ebx = -1059687328, tf_edx = 0, tf_ecx = 0,
tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071849732, tf_cs = 8,
tf_eflags = 66118, tf_esp = 94625792, tf_ss = 0})
at ../../i386/i386/trap.c:423
#10 0xc01cdefc in
Re: disklabels partition sizes differ from FreeBSDs syslog messageson mounting
On Wed, 23 Feb 2000, Andreas Klemm wrote: I'm worried about this message and don't know if I may forget about it or not. I see a discrepany of disklabel partition sizes and those syslog messages I get, when I mount something from my 40GB EIDE disk. Old systems don't support 40GB disks (except in LBA mode, which is broken in other ways). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wierd AMD panics caused by VMWare?
On Wed, 23 Feb 2000, David Gilbert wrote: ... I have half-a-dozen crash dumps of this nature. For me, it always happens in fdcopy(). This may be due to the fact that the machine is running a large apache config --- so fork() is something it's doing often. See PR 16568. pmap_remove_all() doesn't flush the TLB properly in FreeBSD-3.x on i386's. Somehow this doesn't cause many problems, but it fairly reliably breaks the free() in fdfree() when there was a file descriptor larger than about 1000 (this gives a free() of more than MAXALLOCSAVE = 2 pages) when there is a lot of fork() activity. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ffs_blkfree: freeing free block (was Re: Panic (pmap))
:
:In message [EMAIL PROTECTED], Ian Dowse writes:
:
:The fix should be relatively straightforward - either the code should
:avoid linking new indirection blocks until all allocations succeed,
:or it should back out the changes on failure.
:
:Here's one patch that seems to fix the problem. It may not be the best
:approach though?
:
:Ian
I thought of this but I was worried that the softupdates blackmagic
would get broken by it, so my approach is to actually unwind it which,
between inbetween to FSYNC's, should be softupdates-safe.
-Matt
: bap[indirs[i - 1].in_off] = nb;
:+ if (allocib == NULL) {
:+ /*
:+ * Writing bp would link in the newly allocated
:+ * blocks; hold off in case of allocation failure
:+ * later.
:+ */
:+ allocib = bap[indirs[i - 1].in_off];
:+ allocbp = bp;
:+ continue;
:+ }
:...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
Updates on the "moving" symbols problem: The problem with gdb not finding out the type of tzname[] is caused by the shared libs not being built with -g. It probably doesn't have to do with the problem. I appended a tarfile with some test cases. Case 1-3 show different occasions of the error, all dump core when linked dynamically and work fine with -static. 'shlib3.gdb' fed into gdb will show that the symbol address is a moving target. Case 4 is an attempt to reproduce the error I get with tzname[] from libc.so with a newly constructed shared library and a similar symbol. However, this case works fine and I don't understand the difference so far. Set LD_LIBRARY_PATH=`pwd` to run this test case. I have updated two machines to -current from yesterday, no change in the problem. As I suspect the MMU hardwware may influence the problem, here are the CPU ids from the machine I can reproduce the error on (that doesn't mean I have -current machines where the error does not show up): CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV CPU: Pentium/P54C (99.95-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 Let me repeat that this looks like a serious memory mapping bug and that we must not ship 4.0 until we gain more knowledge about it. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 shlib.tar.gz
ad4s1: raw partition size != slice size (was Re: disklabels partition sizes differ from FreeBSDs syslog messages on mounting)
On Wed, Feb 23, 2000 at 12:19:29PM +0100, Andreas Klemm wrote: ad4s1d: start 24322111, end 80035829, size 55713719 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1f: start 5447743, end 13836350, size 8388608 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1g: start 13836351, end 15933502, size 2097152 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1h: start 15933503, end 24322110, size 8388608 After mounting every new filesystem I even get these messages: (after adding fstab and mount -at ufs): ad4s1: raw partition size != slice size ad4s1: start 63, end 12289724, size 12289662 ad4s1c: start 63, end 80035829, size 80035767 ad4s1: truncating raw partition ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1: start 63, end 12289724, size 12289662 ad4s1d: start 24322111, end 80035829, size 55713719 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1f: start 5447743, end 13836350, size 8388608 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1g: start 13836351, end 15933502, size 2097152 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1h: start 15933503, end 24322110, size 8388608 # DeviceMountpoint FStype Options DumpPass# /dev/ad4s2a /newufs rw 1 2 /dev/ad4s2e /new/varufs rw 1 2 /dev/ad4s2f /new/usrufs rw 1 2 /dev/ad4s2g /new/internet ufs rw 1 2 /dev/ad4s2h /new/home ufs rw 1 2 /dev/ad4s2d /new/data ufs rw 1 2 # /dev/rad4c: type: ESDI disk: ad4s2 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 4217 sectors/unit: 67746105 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 26214404.2BSD 1024 819216 # (Cyl.0 - 16*) b: 1048576 262144 swap# (Cyl. 16*- 81*) c: 677461050unused0 0 # (Cyl.0 - 4216) d: 37075257 306708484.2BSD 1024 819216 # (Cyl. 1909*- 4216*) e: 8388608 13107204.2BSD 1024 819216 # (Cyl. 81*- 603*) f: 8388608 96993284.2BSD 1024 819216 # (Cyl. 603*- 1125*) g: 4194304 180879364.2BSD 1024 819216 # (Cyl. 1125*- 1387*) h: 8388608 222822404.2BSD 1024 819216 # (Cyl. 1387*- 1909*) -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Union semun defined in /usr/include/sys/sem.h?
Folks,
I've run into a problem compiling bonnie++ 0.99f and 3.4-STABLE.
Normally, I would ask a question about this on the -stable list, but
from discussions with the author, it's my understanding that this
will probably be fixed in the next revision of the code.
However, this has brought up an interesting question. It is my
understanding that X/Open requires that this union be defined within
the client source code (which is why Russell is going to fix his
code), and not within standard system headers. However, looking in
this file under 3.2-RELEASE and 3.4-STABLE, I find that FreeBSD does
go ahead and define this object.
Is this changed in -CURRENT? If not, are there any plans to
change it in -CURRENT? Or has the X/Open standard changed, and
FreeBSD is following the new standard in this area?
My understanding is that the other BSDs follow the X/Open
standard, as does Linux. I'm trying to understand why FreeBSD is
different in this regard.
I'm also curious to know why there is a difference in how this
object is defined under Linux and FreeBSD. Linux apparently defines
it like so:
union semun {
int val;/* value for SETVAL */
struct semid_ds *buf; /* buffer for IPC_STAT, IPC_SET */
unsigned short int *array; /* array for GETALL, SETALL */
struct seminfo *__buf; /* buffer for IPC_INFO */
};
#endif
Whereas looking in /usr/include/sys/sem.h, FreeBSD defines it like so:
union semun {
int val;/* value for SETVAL */
struct semid_ds *buf; /* buffer for IPC_STAT IPC_SET */
u_short *array; /* array for GETALL SETALL */
};
At the end of the day, I'm just trying to get a working bonnie++.
However, I'm also interested as to who is "right" on this issue, and
more importantly, why they are "right".
Thanks!
--
These are my opinions and should not be taken as official Skynet policy
_
|o| Brad Knowles, [EMAIL PROTECTED] Belgacom Skynet NV/SA |o|
|o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o|
|o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o|
|o| http://www.skynet.be Belgium |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
Unix is very user-friendly. It's just picky who its friends are.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: thanks for your nice help ! (was Re: timeout problems ....)
It seems Andreas Klemm wrote: On Tue, Feb 22, 2000 at 10:15:42PM +0100, Soren Schmidt wrote: There are two posibilities, either the cable is bad or the disk is bad. Since you could talk to it, and you didn't get ICRC errors, my bet is that the particular Maxtor model is just as broken as most of its other family memebers :( Hmm, too bad. But o.k. actually it's working now and a big thanks for your kind support !!! You're welcome :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
routed dumping core?
Before I go off and sink a huge amount of time into this, I was wondering if anybody else was noticing that routed in 4.0-rc2 was dumping core within a minute of the system starting. We have 4 different machines that this is hitting right now, but have not had the time to track it down any further than this. If this isn't a known problem, I'll dig further and put the time in to find/kill the bug, but I hadn't seen anything here so I thought I'd ask. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 3.9.18
That's odd... I just built it tonight, and I havn't had anything but this: XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 Which doesn't cause the server to crash, in fact, it seems pretty stable. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Wed, 23 Feb 2000, Donn Miller wrote: I've built this thing on -current recently, and I'l getting the weirdest errors when I try to start X: (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 3 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 9 - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic #3 (ffs) (MegaRAID)
At 08:30 PM 2/23/00 +0100, Karsten W. Rohrbach wrote: which megaraid adapter do you use in this box (hw, fw ver, bios ver, cntl-m ver)... i've seen those panics on our old news box when there where errors on the scsi busses which did not get detected properly. mainly termination issues *sigh* I dont think its necessarily a termination issue. I have swapped the exact same chain onto a Mylex DAC960 and can pound the box without issue. I have a nasty feeling my 466 might not like my MB chipset. I am using a 466 PERC2/SC on BX chipset ECS MB and its throwing all sorts of fits. When I used a 428 on another box (a plain old Pentium), I didnt have nearly this many problems. Soon as my co-worker is finished with the older Pentium, I can test this theory to see if this is the case. Looking at the release notes for the BIOS revs at AMI, it seems older BIOS revs might have problems with newer MBs From ftp://ftp.megatrends.com/MegaRAID/drivers/466/readme-gh6d.txt Changes in this release: --- 1. CTRL-M is not invoked until after the system BIOS is completed on newer systems that support PMM (POST Memory Management). The system would hang at different places in CTRL-M on these systems prior to these changes. Until I flashed it to this new rev, I was seeing this behaviour. Just to reiterate; I can reliably hang the 466 running with this firmware within a few minutes under the 'amr' driver, while the Dell 3.00 firmware doesn't demonstrate the config-time hangs on any system I've run it on and is also not susceptible to the hang problems. I've been a little distracted with various Mylex-related issues for a little bit now, and am still waiting for some response from AMI before returning to work on these problems. I'm also in need of a more or less permanent loan of a 434 or 438 (preferably) controller as all I have right now are 418/428/466 and Karsten's been reporting issues with all of the 438's firmware. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
On 23-Feb-00 Kenneth D. Merry wrote: Well, Alexander Leidinger's suggestion of disabling Javascript seems to help. I disabled both JavaScript and Style Sheets (in the "advanced" preferences menu) and in relatively limited testing, Slashdot didn't crash Netscape for me. If you login to /. you can change your preferences to be 'simple HTML' which makes it not crash netscape and load faster too.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrade from 3.4 to 4.0...
On Tue, Feb 22, 2000 at 11:08:54PM -0800, William Woods wrote: It did, although I did eventually remake them. I did: mv /dev /dev.old mkdir /dev cp /usr/src/etc/MAKE* /dev sh MAKEDEV all This makes sence I also had to make the partition entries for my IDE drive: sh MAKEDEV ad0s4a Ahhok. So if my partitions are thus: /dev/wd0s1a 9229851 2248506 624295726%/ procfs 440 100%/proc I would do?? Do nothing, except upgrade your /dev and /etc, just like you did it when you were tracking -stable. The new ata(4) driver supports old wd(4) names, i.e. it will accept both new adX and old wdX names. -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
On Tue, Feb 22, 2000 at 03:16:00AM -0500, Donn Miller wrote: I can give you the .mozconfig file I used to successfully build Mozilla on -current. Patches to make the port compile on Current? :-) -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
[CC'ed David, since the new compiler seems to cause the problems]
Sorry for the update bombing, but I found that the file where the
tzname symbol is being defined in triggers this error mesage in a
`make world`:
cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale
-DBROKEN_DES -DYP -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/lib/libc/../libc/stdtime/localtime.c -o localtime.So
{standard input}: Assembler messages:
{standard input}:87: Warning: warning: unrecognized characters
`@GOTOFF' in expression
{standard input}:114: Warning: warning: unrecognized characters
`@GOTOFF' in expression
The assembler code looks like this (not that it is surrounding the
symbol we have problems with):
.L18:
leal (%edi,%edi,4),%edx
leal 1868+lclmem@GOTOFF(%ebx),%eax [1]
leal (%eax,%edx,4),%edx
movl tzname@GOT(%ebx),%esi
movl 4(%edx),%ecx
sall $2,%ecx
movl %ebx,%eax
addl 8(%edx),%eax
addl $6988+lclmem@GOTOFF,%eax [2]
movl %eax,(%ecx,%esi)
incl %edi
movl -4(%ebp),%eax
cmpl 8(%eax),%edi
jl .L18
Note that 'as' complains about [2], [1] is fine.
I'm not that familar with gas syntax, but it seems to be that this is
a syntax error generated by the new gcc, that @GOTOFF must be passed
one argument.
/usr/src/contrib/gcc/config/i386/i386.c:2988 seems to be the line that
writes the GOTOFF without an argument.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
On Wed, 23 Feb 2000, David O'Brien wrote: On Tue, Feb 22, 2000 at 03:16:00AM -0500, Donn Miller wrote: I can give you the .mozconfig file I used to successfully build Mozilla on -current. Patches to make the port compile on Current? :-) Well, I've been checking out the source code to Mozilla about 2X a week (via cvs -z3 co SeaMonkeyAll), and building it on my own... I see they've fixed some stuff since M13. But, putting the right stuff in .mozconfig can be tricky. If you put certain things in there, the build will bomb out. BTW, I noticed there's certain bugs with gcc's optimization code. For example, I used '-mpentium -O3 -pipe' as the optimization flags in building the latest Qt snapshot. If I used those CFLAGS I described, the build bombs out with "Internal compiler error". When I reverted back to the stock CFLAGS for the Qt build (-O2 -pipe), the errors went away. I guess I really don't have to build _everything_ on the planet with -mpentium -O3 -pipe. I noticed that most gcc "Internal compiler errors" are caused by using high optimization levels. I really didn't notice that big an increase in performance, anyways. The performance increase was about on par with changing the air filter in your car. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic (pmap)
And I may welcome panic #6 here. db trace pmap_remove_all(5a3e000,c061ab70,0,c0230ac0,d62a2f8c) at pmap_remove_all+0x40 pmap_page_protect(5a3e000,0) at pmap_page_protect+0xde vm_pageout_page_stats(0) at vm_pageout_page_stats+0x15e vm_pageout(0) at vm_pageout+0x1fb fork_trampoline() at fork_trampoline+0x8 Dumping system to disk, and will put out the gdb bt when it's done doing that. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem with IBM Netfinity 5000 Server (with dmesg)
Sorry for sending you all the messages from /var/log/messages, here is dmesg as the NIC at 5th PCI slot, Sorry for I cannot got dmesg as the NIC at 4th PCI slot, server reboot and I lost every things Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Wed Feb 23 13:56:44 CST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/www Calibrating clock(s) ... TSC clock: 498602083 Hz, i8254 clock: 1193024 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 498670656 Hz CPU: Pentium III/Pentium III Xeon (498.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 536854528 (524272K bytes) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0031c000 - 0x1fff3fff, 533561344 bytes (130264 pages) avail memory = 517894144 (505756K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fd5d0 bios32: Entry = 0xfd5e1 (c00fd5e1) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xd61c pnpbios: Found PnP BIOS data at 0xc00fde90 pnpbios: Entry = f:497d Rev = 1.0 Other BIOS signatures found: ACPI: 000fdec0 Preloaded elf kernel "kernel" at 0xc0303000. Pentium Pro MTRR support enabled Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x0070 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00071166) npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00071166) pcib0: Host to PCI bridge on motherboard found- vendor=0x1166, dev=0x0007, revid=0x04 class=06-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base , size 0 found- vendor=0x1166, dev=0x0005, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x1229, revid=0x05 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base febff000, size 12 map[14]: type 1, range 32, base 2000, size 5 map[18]: type 1, range 32, base fea0, size 20 found- vendor=0x9004, dev=0x7895, revid=0x04 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=15 map[10]: type 1, range 32, base 2200, size 8 map[14]: type 1, range 32, base febfe000, size 12 found- vendor=0x9004, dev=0x7895, revid=0x04 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=b, irq=10 map[10]: type 1, range 32, base 2300, size 8 map[14]: type 1, range 32, base febfd000, size 12 found- vendor=0x1022, dev=0x2000, revid=0x36 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base 2020, size 5 map[14]: type 1, range 32, base febfcc00, size 5 found- vendor=0x5333, dev=0x8901, revid=0x16 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base f800, size 26 found- vendor=0x1166, dev=0x0200, revid=0x4d class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x1166, dev=0x0210, revid=0x4a class=01-01-ea, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=14 map[10]: type 1, range 32, base 01f0, size 3 map[14]: type 1, range 32, base 03f4, size 2 map[18]: type 1, range 32, base 0010, size 3 map[1c]: type 1, range 32, base , size 2 map[20]: type 1, range 32, base ffa0, size 4 found- vendor=0x1166, dev=0x0220, revid=0x04 class=0c-03-10, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base ff70, size 12 pci0: PCI bus on pcib0 fxp0: Intel EtherExpress Pro 10/100B Ethernet port 0x2000-0x201f mem 0xfea0-0xfeaf,0xfebff000-0xfebf irq 11 at device 1.0 on pci0 fxp0: Ethernet address 00:04:ac:45:75:fc bpf: fxp0 attached ahc0: Adaptec aic7895 Ultra SCSI adapter port 0x2200-0x22ff mem 0xfebfe000-0xfebfefff irq 15 at device 6.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Low byte termination Enabled ahc0: High byte
thanks for your nice help ! (was Re: timeout problems ....)
On Tue, Feb 22, 2000 at 10:15:42PM +0100, Soren Schmidt wrote: There are two posibilities, either the cable is bad or the disk is bad. Since you could talk to it, and you didn't get ICRC errors, my bet is that the particular Maxtor model is just as broken as most of its other family memebers :( Hmm, too bad. But o.k. actually it's working now and a big thanks for your kind support !!! -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic (pmap)
On Wed, Feb 23, 2000 at 11:01:39AM +0100, Jeroen Ruigrok van der Werven wrote: Current score: 1 tcp panic 1 pmap panic 4 ffs panics Such a mix might suggests bad hardware? (Mind you, we're seeing "freeing free block" panics on a NFS server with full disks on 3.4). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabels partition sizes differ from FreeBSDs syslog messages on mounting
Hi ! I'm worried about this message and don't know if I may forget about it or not. I see a discrepany of disklabel partition sizes and those syslog messages I get, when I mount something from my 40GB EIDE disk. I did a normal FreeBSD 4.0 SNAP installation on a new 40 GB disk. On the largest filesystem I wanted to backup my old system. So I mounted now the ata disk under my SCSI environment, to do a backup. Please note: I did no manual fiddeling with disklabel or such on the EIDE disk, it was a normal installation from self burned CD and doing a custom installation. When I try to mount the largest filesystem from the EIDE disk I get these syslog messages and this worries me: ad4s1d: start 24322111, end 80035829, size 55713719 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1f: start 5447743, end 13836350, size 8388608 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1g: start 13836351, end 15933502, size 2097152 ad4s1: rejecting partition in BSD label: it isn't entirely within the slice ad4s1h: start 15933503, end 24322110, size 8388608 Look at the different partition sizes, I made a tabular, some values are equal, some greater, some less, no clear picture to me: ad4s1d:start 24322111, end 80035829, size 55713719 disklabel -r at4 value: 37075257 ad4s1f:start 5447743, end 13836350, size 8388608 disklabel -r at4 value: 8388608 = ad4s1g:start 13836351, end 15933502, size 2097152 disklabel -r at4 value: 4194304 ad4s1h:start 15933503, end 24322110, size 8388608 disklabel -r at4 value: 8388608 = kernel in core disklabel and on the disk are the same: This is thew exact output: disklabel -r ad4 # /dev/rad4c: type: ESDI disk: ad4s2 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 4217 sectors/unit: 67746105 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 26214404.2BSD 1024 819216 # (Cyl.0 - 16*) b: 1048576 262144 swap# (Cyl. 16*- 81*) c: 677461050unused0 0 # (Cyl.0 - 4216) d: 37075257 306708484.2BSD 1024 819216 # (Cyl. 1909*- 4216*) e: 8388608 13107204.2BSD 1024 819216 # (Cyl. 81*- 603*) f: 8388608 96993284.2BSD 1024 819216 # (Cyl. 603*- 1125*) g: 4194304 180879364.2BSD 1024 819216 # (Cyl. 1125*- 1387*) h: 8388608 222822404.2BSD 1024 819216 # (Cyl. 1387*- 1909*) And here for reference the output of /stand/sysinstall: Disk name: ad4FDISK Partition Editor DISK Geometry: 4982 cyls/255 heads/63 sectors = 80035830 sectors Offset SizeEnd Name PType Desc SubtypeFlags 0 63 62- 6 unused0 63 12289662 12289724ad4s1 2fat 11 12289725 67746105 80035829ad4s2 3freebsd 165C 80035830 5418 80041247- 6 unused0 And here what the kernel says: ad4: 39082MB Maxtor 54098U8 [79406/16/63] at ata2-master using UDMA33 Any thoughts ... should I simply install or better wait ??? ;-) -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
On 22 Feb, Steve Hocking wrote: There was some discussion of this over on the XFree mailing lists, and it transpired that netscape was using a pointer to some memory that had been freed some time back. This showed up in cases where you open up a stack of windows and then close them at random. There was a patch to work around this for libXt (I think). But this didn't solve the crash at exit. But... rm -rf /usr/lib/compat/* cd /usr/src/lib/compat/compat22/ make all install clean cd ../compat3x.i386/ make all install clean solved this for me (YMMV). Together with disabling Java* and using those ---snip--- Netscape*dragInitiatorProtocolStyle:XmDRAG_NONE Netscape*dragReceiverProtocolStyle: XmDRAG_NONE ---snip--- Xresources I have a more stable Netscape. Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't load if_xl module at startup
On Mon, 21 Feb 2000 18:47:48 +0100, [EMAIL PROTECTED] wrote: When I load the if_xl module "by hand", all is well : the miibus is also loaded and everything's fine (xl0 appears in ifconfig -a ...) When I try to load the if_xl and miibus modules via the loader, the loader spins in : I'm answering because you don't seem to have gotten any other (public) answers, not because I'm sure of my facts. Quite a few people have reported problems loading modules from the loader (different modules, mind you). I'm pretty sure that I saw a clueful person suggest loading them out of /etc/rc.local for now. I can't check the archives to validate this, so you might want to think about it more than I have. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
On Wed, 23 Feb 2000, Martin Cracauer wrote:
cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale
-DBROKEN_DES -DYP -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/lib/libc/../libc/stdtime/localtime.c -o localtime.So
{standard input}: Assembler messages:
{standard input}:87: Warning: warning: unrecognized characters
`@GOTOFF' in expression
{standard input}:114: Warning: warning: unrecognized characters
`@GOTOFF' in expression
I'm not that familar with gas syntax, but it seems to be that this is
a syntax error generated by the new gcc, that @GOTOFF must be passed
one argument.
The syntax seems reasonable, but our version of gas doesn't support it,
and it is the result of a pessimisation. I tweaked the source code to
avoid the bad code:
diff -c2 localtime.c~ localtime.c
*** localtime.c~Fri Jan 28 17:29:18 2000
--- localtime.c Wed Feb 23 22:51:34 2000
***
*** 220,224
settzname P((void))
{
! register struct state * const sp = lclptr;
register inti;
--- 220,224
settzname P((void))
{
! register struct state * sp = lclptr;
register inti;
This seems to fix some of your prooblems.
It works as follows: when sp is declared as const, gcc decides not to
keep in a register in the default !ALL_STATE case (lclptr is lclmem in
this case), since it can "easily" be recovered by computing the address
constant lclmem. However, computing the constant turns out to be not
so easy in the -fpic case -- it takes an extra 8 instructions, including
a pessimization which gives the bug. (The natural and efficient way
to reload lclptr (plus an offset) is:
leal offset+lclmem@GOTOFF(%ebx),%reg
but for some reason this sometimes gets pessimized to essentially:
movl %ebx,%reg
addl offset+lclmem@GOTOFF,%reg
The last instruction is a syntax error with the current gas.)
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: can't load if_xl module at startup
Hello, Well, this is exactly what I've conluded : don't use the loader for now (I've recompiled my kernel). I had a mail exchange with Mike Smith (on -Current) and I told him I would very much like to have a committer add a comment in /boot/loader.conf telling newbies about with little problem (don't know if I was heard) TfH Sheldon Hearn [EMAIL PROTECTED] on 23/02/2000 12:09:53 To: Thierry HERBELOT/FR/ALCATEL@ALCATEL cc: [EMAIL PROTECTED] Subject: Re: can't load if_xl module at startup On Mon, 21 Feb 2000 18:47:48 +0100, [EMAIL PROTECTED] wrote: When I load the if_xl module "by hand", all is well : the miibus is also loaded and everything's fine (xl0 appears in ifconfig -a ...) When I try to load the if_xl and miibus modules via the loader, the loader spins in : I'm answering because you don't seem to have gotten any other (public) answers, not because I'm sure of my facts. Quite a few people have reported problems loading modules from the loader (different modules, mind you). I'm pretty sure that I saw a clueful person suggest loading them out of /etc/rc.local for now. I can't check the archives to validate this, so you might want to think about it more than I have. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: extern variables in shared libraries broken (ld.so or mmap bug)
In [EMAIL PROTECTED], Bruce Evans wrote:
diff -c2 localtime.c~ localtime.c
*** localtime.c~ Fri Jan 28 17:29:18 2000
--- localtime.c Wed Feb 23 22:51:34 2000
***
*** 220,224
settzname P((void))
{
! register struct state * const sp = lclptr;
register inti;
--- 220,224
settzname P((void))
{
! register struct state * sp = lclptr;
register inti;
This seems to fix some of your prooblems.
It works as follows: when sp is declared as const, gcc decides not to
keep in a register in the default !ALL_STATE case (lclptr is lclmem in
this case), since it can "easily" be recovered by computing the address
constant lclmem. However, computing the constant turns out to be not
so easy in the -fpic case -- it takes an extra 8 instructions, including
a pessimization which gives the bug.
My initial next question would be how this bad code in localtime.c can
affect straight references from the calling program to the symbol
tzname[] without calling code in localtime. And why write accesses
succeed and read accesses fail.
Looking on the assembler code, I guess that the wrong code in
localtime.c leave a wrong value in %ecx, why is used as a base address
by rtld.
Once the wrong code is called, the symbol table is messed up. However,
some calls such as the write test in my shlibs3 example still succeed
because the compiler saved/cached the address from a previous call
(which he is allowed to since the address is constant). Once the code
goes through normal rtld lookup again, it bombs.
Right?
I am not sure how harmless this bug is. `make world` output shows that
the as warning message only occurs in localtime.c. I think a
workaround might be to fix as you suggest and turn the assembler
warning into an error, although in that case users might not be able
to compile valid code into shared libraries.
Where's the bug, anyway? Do we need to fix the compiler or would it be
better to get a newer assembler?
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Wierd AMD panics caused by VMWare?
I had reported this earlier, but the similarities are striking:
I too have seen strange AMD panics where stack variables inexplicably
go to zero. My systems are K6/2-400's, and I have often witnessed the
following fault (only happens on a *really* busy web server)
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc014aad1 in panic (fmt=0xc023878a "page fault")
at ../../kern/kern_shutdown.c:446
#2 0xc02098ce in trap_fatal (frame=0xcc74eecc, eva=134812896)
at ../../i386/i386/trap.c:942
#3 0xc0209587 in trap_pfault (frame=0xcc74eecc, usermode=0, eva=134812896)
at ../../i386/i386/trap.c:835
#4 0xc02091ba in trap (frame={tf_es = -887750640, tf_ds = -1036058608,
tf_edi = -1050208512, tf_esi = -1043943040, tf_ebp = -864751828,
tf_isp = -864751884, tf_ebx = 2287, tf_edx = -1036043576, tf_ecx = 0,
tf_eax = 134812884, tf_trapno = 12, tf_err = 2, tf_eip = -1072417321,
tf_cs = 8, tf_eflags = 66054, tf_esp = -1041509376, tf_ss = -1036024832})
at ../../i386/i386/trap.c:437
#5 0xc01435d7 in fdcopy (p=0xcc5796e0) at ../../kern/kern_descrip.c:954
#6 0xc014587b in fork1 (p1=0xcc5796e0, flags=-2147483596)
at ../../kern/kern_fork.c:379
#7 0xc014533b in vfork (p=0xcc5796e0, uap=0xcc74ef94)
at ../../kern/kern_fork.c:109
#8 0xc0209b17 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 236237520,
tf_esi = 236231856, tf_ebp = -1077952324, tf_isp = -864751644,
tf_ebx = 673171048, tf_edx = 163766316, tf_ecx = 672877149, tf_eax = 66,
tf_trapno = 7, tf_err = 2, tf_eip = 672936705, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077952368, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#9 0xc01feedc in Xint0x80_syscall ()
Now the interesting code here is at stack from #5:
(kgdb) list
948 fpp = newfdp-fd_ofiles;
949 for (i = newfdp-fd_lastfile; i-- = 0; fpp++)
950 if (*fpp != NULL)
951 (*fpp)-f_count++;
(kgdb) p newfdp-fd_ofiles
$1 = (struct file **) 0xc23f2000
(kgdb) p fpp
$2 = (struct file **) 0x0
Now... the only operation on fpp is fpp++. It should take a _long_
time for fpp to get around to 0 and you'd thing that *fpp would be
zero long before that (or cause a page fault at some other
non-existant location).
So... the similarity here is that deep in the kernel, we have a
automatic (possibly register) local variable that's getting zero'd.
I have half-a-dozen crash dumps of this nature. For me, it always
happens in fdcopy(). This may be due to the fact that the machine is
running a large apache config --- so fork() is something it's doing
often.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: disklabels partition sizes differ from FreeBSDs syslog messages on mounting
On Wed, Feb 23, 2000 at 11:43:32PM +1100, Bruce Evans wrote: On Wed, 23 Feb 2000, Andreas Klemm wrote: I'm worried about this message and don't know if I may forget about it or not. I see a discrepany of disklabel partition sizes and those syslog messages I get, when I mount something from my 40GB EIDE disk. Old systems don't support 40GB disks (except in LBA mode, which is broken in other ways). Hi Bruce, what do you mean exactly with "old systems" ? Correct me if I'm wrong, but I don't "old hardware", since I have a *brand new* EIDE controller (Abit) which _is_ capable of recognizing the 40 GB harddisk. Please look here: FreeBSD is able to detect the drive in it's full size, kernel message: ad4: 39082MB Maxtor 54098U8 [79406/16/63] at ata2-master using UDMA33 79406*16*63= 80041248 sectors FreeBSD offers during installation to use a more clever partitioning scheme (sector translation). The values seem reasonable for me: Systinstall displays in the first line: 4982 cyls/255 heads/63 sectors = 80035830 sectors 4982*255*63= 80035830 which is smaller than the total sector size of the drive (80041248) Disklabel also has reasonable entries: sectors/track: 63 tracks/cylinder: 255 cylinders: 4217 sectors/unit: 67746105 255*63*4217= 67746105 which should be the size of my FreeBSD slice Could you please be more verbose on what's going wrong in your opineon ? I assume you might have missed the point, that I use a brand new EIDE controller and turned off on board IDE ... Anyway, thanks for your answer Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic #3 (ffs)
*sigh*
I think I am going to give up my job and become a buddhist monk...
start = 0, len = 2646, fs = /news
panic: ffs_alloccg: map corrupted
Debugger("panic")
Stopped at Debugger+0x35: movb$0,in_Debugger.372
db trace
Debugger(c01e7ee3) at Debugger+0x35
panic(c01f28bf,c01f28a0,0,a56,c1d0d8d4) at panic+0x70
ffs_mapsearch(c1d0d800,ccd49000,5d2a8,1,b) at ffs_mapsearch+0x143
ffs_alloccg(c1da7700,b,5d2a8,400) at ffs_alloccg+0x21a
ffs_hashalloc(c1da7700,b,5d2a8,400,c0194cb8) at ffs_hashalloc+0x23
ffs_alloc(c1da7700,b,5d2a8,400,c1d38280) at ffs_alloc+0xad
ffs_balloc(d8a1ce68,d8a4c200,c1d6a180,3,d8b74ba0) at ffs_balloc+0x456
ffs_write(d8a1cea0,d6299a80,4c,c1d6a180,c0201d00) at ffs_write+0x319
vn_write(c1d6a180,d8a1ceec,c1d38280,0,d6299a80) at vn_write+0xda
dofilewrite(d6299a80,c1d6a180,18,280c4000,4c) at dofilewrite+0x91
write(d6299a80,d8a1cf80,280ad140,280ad140,280c404d) at write+0x33
syscall(280c002f,280a002f,bfbf002f,280c404d,280ad140) at syscall+0x176
Xint0x80_syscall() at Xint0x80_syscall+0x26
--
Jeroen Ruigrok van der Werven Network- and systemadministrator
[EMAIL PROTECTED] bART Internet Services /
BSD: Technical excellence at its best VIA NET.WORKS Netherlands
Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Wierd AMD panics caused by VMWare?
The only thing I would add is that by AMD I didn't mean
Advanced Micro Devices. I meant /usr/sbin/amd. In my case
this behavior has been observed on a Pentium III and on a
K7, so it's CPU independent.
David Gilbert wrote:
I had reported this earlier, but the similarities are striking:
I too have seen strange AMD panics where stack variables inexplicably
go to zero. My systems are K6/2-400's, and I have often witnessed the
following fault (only happens on a *really* busy web server)
The common denominator seems to be that the machine has to be very
active. VMware stresses the vm system quite a bit (64M of shared
memory with multiple processes digging around, etc). A very busy
web server is going to do a lot of context switching (I think?).
In that situation, it appears that the stack is being smashed.
I tried insulating the code where my machines go nuts inside of
splhigh() / splx(), but it didn't help.
Is your machine running the automounter?
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc014aad1 in panic (fmt=0xc023878a "page fault")
at ../../kern/kern_shutdown.c:446
#2 0xc02098ce in trap_fatal (frame=0xcc74eecc, eva=134812896)
at ../../i386/i386/trap.c:942
#3 0xc0209587 in trap_pfault (frame=0xcc74eecc, usermode=0, eva=134812896)
at ../../i386/i386/trap.c:835
#4 0xc02091ba in trap (frame={tf_es = -887750640, tf_ds = -1036058608,
tf_edi = -1050208512, tf_esi = -1043943040, tf_ebp = -864751828,
tf_isp = -864751884, tf_ebx = 2287, tf_edx = -1036043576, tf_ecx = 0,
tf_eax = 134812884, tf_trapno = 12, tf_err = 2, tf_eip = -1072417321,
tf_cs = 8, tf_eflags = 66054, tf_esp = -1041509376, tf_ss = -1036024832})
at ../../i386/i386/trap.c:437
#5 0xc01435d7 in fdcopy (p=0xcc5796e0) at ../../kern/kern_descrip.c:954
#6 0xc014587b in fork1 (p1=0xcc5796e0, flags=-2147483596)
at ../../kern/kern_fork.c:379
#7 0xc014533b in vfork (p=0xcc5796e0, uap=0xcc74ef94)
at ../../kern/kern_fork.c:109
#8 0xc0209b17 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 236237520,
tf_esi = 236231856, tf_ebp = -1077952324, tf_isp = -864751644,
tf_ebx = 673171048, tf_edx = 163766316, tf_ecx = 672877149, tf_eax = 66,
tf_trapno = 7, tf_err = 2, tf_eip = 672936705, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077952368, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#9 0xc01feedc in Xint0x80_syscall ()
Now the interesting code here is at stack from #5:
(kgdb) list
948 fpp = newfdp-fd_ofiles;
949 for (i = newfdp-fd_lastfile; i-- = 0; fpp++)
950 if (*fpp != NULL)
951 (*fpp)-f_count++;
(kgdb) p newfdp-fd_ofiles
$1 = (struct file **) 0xc23f2000
(kgdb) p fpp
$2 = (struct file **) 0x0
Now... the only operation on fpp is fpp++. It should take a _long_
time for fpp to get around to 0 and you'd thing that *fpp would be
zero long before that (or cause a page fault at some other
non-existant location).
So... the similarity here is that deep in the kernel, we have a
automatic (possibly register) local variable that's getting zero'd.
I have half-a-dozen crash dumps of this nature. For me, it always
happens in fdcopy(). This may be due to the fact that the machine is
running a large apache config --- so fork() is something it's doing
often.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Wierd AMD panics caused by VMWare?
"Nick" == Nick Sayer [EMAIL PROTECTED] writes: Nick The only thing I would add is that by AMD I didn't mean Advanced Nick Micro Devices. I meant /usr/sbin/amd. In my case this behavior Nick has been observed on a Pentium III and on a K7, so it's CPU Nick independent. Nick The common denominator seems to be that the machine has to be Nick very active. VMware stresses the vm system quite a bit (64M of Nick shared memory with multiple processes digging around, etc). A Nick very busy web server is going to do a lot of context switching Nick (I think?). In that situation, it appears that the stack is Nick being smashed. Nick I tried insulating the code where my machines go nuts inside of Nick splhigh() / splx(), but it didn't help. Nick Is your machine running the automounter? No... but someone sent me some patches that deal with file descriptor coruption that may (or may not) solve my problem. It at least sounds plausable. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Things to consider in CURRENT
I did this via /stand/sysinstall - Configure packages from the RELENG-4 server, on a brand new installed 4.0-2208-CURRENT - Original Message - From: "Garance A Drosihn" [EMAIL PROTECTED] To: "Morten Seeberg" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 21, 2000 7:20 PM Subject: Re: Things to consider in CURRENT At 4:47 PM +0100 2/21/00, Morten Seeberg wrote: Hi, I just installed: FreeBSD fw.home 4.0-2208-CURRENT and have a few comments: It seems that BASH in 4.x needs Combat 3.x, but why cant BASH work this out for it self? One day when installing BSD without X (which automatically installs Combat 3.x) I couldnt start it without. How did you do the install? Did you do an "install from scratch", or did you build over a system you already had running a previous release of freebsd? --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic (pmap)
:On Wed, Feb 23, 2000 at 11:01:39AM +0100, Jeroen Ruigrok van der Werven wrote: : : Current score: : : 1 tcp panic : 1 pmap panic : 4 ffs panics : :Such a mix might suggests bad hardware? : :(Mind you, we're seeing "freeing free block" panics on a NFS server :with full disks on 3.4). : : David. With softupdates turned on? Softupdates has known problems when a disk runs out of space. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic (pmap)
Matthew Dillon wrote: :On Wed, Feb 23, 2000 at 11:01:39AM +0100, Jeroen Ruigrok van der Werven wrote: : : Current score: : : 1 tcp panic : 1 pmap panic : 4 ffs panics : :Such a mix might suggests bad hardware? : :(Mind you, we're seeing "freeing free block" panics on a NFS server :with full disks on 3.4). : : David. With softupdates turned on? Softupdates has known problems when a disk runs out of space. didn't kirk just fix that? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
softdep out of space should be fixed Re: Panic (pmap)
* Matthew Dillon [EMAIL PROTECTED] [000223 09:55] wrote: : : David. : : With softupdates turned on? Softupdates has known problems when a : disk runs out of space. : :didn't kirk just fix that? : : __--_|\ Julian Elischer I don't recall it being fixed. It _should_ be fixed in both 4.0 (rev 1.25) and 3.4 (rev 1.21.2.2+1.21.2.3) of src/sys/ufs/ffs/ffs_balloc.c -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ffs_blkfree: freeing free block (was Re: Panic (pmap))
In message [EMAIL PROTECTED], Matthew Dillon writes:
:(Mind you, we're seeing "freeing free block" panics on a NFS server
:with full disks on 3.4).
:
: David.
With softupdates turned on? Softupdates has known problems when a
disk runs out of space.
No, softupdates is not enabled on this filesystem. Other filesystems
on the same machine that are used lightly and are not full do have
softupdates enabled though. (we have v1.21.2.3 of ffs_balloc.c anyway)
The panics have been occurring every few days recently, and their timing
always corresponds within a few minutes to the filesystem becoming full
(/var/log/messages will have a flurry of 'file system full' messages
just before the reboot).
An example trace is below. Let me know if any further information would
be useful.
Ian
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc0148311 in panic (fmt=0xc0234c11 "ffs_blkfree: freeing free block")
at ../../kern/kern_shutdown.c:446
#2 0xc01ca29f in ffs_blkfree (ip=0xc2303000, bno=18512, size=8192)
at ../../ufs/ffs/ffs_alloc.c:1328
#3 0xc01ccab2 in ffs_indirtrunc (ip=0xc2303000, lbn=-2061, dbn=15492288,
lastbn=-1, level=1, countp=0xcb2aab2c) at ../../ufs/ffs/ffs_inode.c:498
#4 0xc01cc528 in ffs_truncate (vp=0xcb3f1cc0, length=0, flags=0,
cred=0xc21a8f84, p=0xcb254700) at ../../ufs/ffs/ffs_inode.c:315
#5 0xc01d8ca9 in ufs_setattr (ap=0xcb2aac98) at ../../ufs/ufs/ufs_vnops.c:493
#6 0xc01db11d in ufs_vnoperate (ap=0xcb2aac98)
at ../../ufs/ufs/ufs_vnops.c:2300
#7 0xc01956f8 in nfsrv_setattr (nfsd=0xc21a8f00, slp=0xc20c4d00,
procp=0xcb254700, mrq=0xcb2aae34) at vnode_if.h:275
#8 0xc01aec96 in nfssvc_nfsd (nsd=0xcb2aae94, argp=0x8072b64 "", p=0xcb254700)
at ../../nfs/nfs_syscalls.c:652
#9 0xc01ae5e1 in nfssvc (p=0xcb254700, uap=0xcb2aaf94)
at ../../nfs/nfs_syscalls.c:342
#10 0xc0204be3 in syscall (frame={tf_es = 39, tf_ds = -1078001625,
tf_edi = 16, tf_esi = 4, tf_ebp = -1077944908, tf_isp = -886394908,
tf_ebx = 0, tf_edx = 3, tf_ecx = 3, tf_eax = 155, tf_trapno = 12,
tf_err = 2, tf_eip = 134519880, tf_cs = 31, tf_eflags = 662,
tf_esp = -1077945308, tf_ss = 39}) at ../../i386/i386/trap.c:1100
#11 0xc01fa16c in Xint0x80_syscall ()
#12 0x80480e9 in ?? ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: disklabels partition sizes differ from FreeBSDs syslog messageson mounting
On Wed, 23 Feb 2000, Andreas Klemm wrote: On Wed, Feb 23, 2000 at 11:43:32PM +1100, Bruce Evans wrote: Old systems don't support 40GB disks (except in LBA mode, which is broken in other ways). what do you mean exactly with "old systems" ? FreeBSD-3.x, or FreeBSD--current with the wd driver. Please look here: FreeBSD is able to detect the drive in it's full size, kernel message: ad4: 39082MB Maxtor 54098U8 [79406/16/63] at ata2-master using UDMA33 79406*16*63= 80041248 sectors Old systems only support 65536 cylinders. (All FreeBSD drivers only support 65556 sectors in CHS mode.) Disklabel also has reasonable entries: sectors/track: 63 tracks/cylinder: 255 cylinders: 4217 sectors/unit: 67746105 255*63*4217= 67746105 which should be the size of my FreeBSD slice This is reasonable if the slice isn't [nearly] the whole disk. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PATCH: partial fix for PR 16587 can't record with CS423x
Partial fix: the following patch correctly configures the card for dual channel DMA. The problem was that the SDC bit (0x04) can only be set in the MCE state. So now recording doesn't hang, and data is returned, but the recorded sound doesn't sound right when played back. Anybody have an idea why? --- mss.c.orig Wed Feb 23 11:04:23 2000 +++ mss.c Fri Jan 28 16:18:28 2000 @@ -92,8 +92,6 @@ static int ad_read(struct mss_info *mss, int reg); static voidad_write(struct mss_info *mss, int reg, u_char data); static voidad_write_cnt(struct mss_info *mss, int reg, u_short data -static voidad_enter_MCE(struct mss_info *mss); -static voidad_leave_MCE(struct mss_info *mss); /* io primitives */ static voidconf_wr(struct mss_info *mss, u_char reg, u_char data); @@ -467,9 +465,7 @@ } if (FULL_DUPLEX(mss) mss-bd_id != MD_OPTI931) ad_write(mss, 12, ad_read(mss, 12) | 0x40); /* mode 2 */ - ad_enter_MCE(mss); ad_write(mss, 9, FULL_DUPLEX(mss)? 0 : 4); - ad_leave_MCE(mss); ad_write(mss, 10, 2); /* int enable */ io_wr(mss, MSS_STATUS, 0); /* Clear interrupt status */ /* the following seem required on the CS4232 */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: partial fix for PR 16587 can't record with CS423x
Doh! Sorry, I reversed the patch. Matt Matthew Reimer wrote: Partial fix: the following patch correctly configures the card for dual channel DMA. The problem was that the SDC bit (0x04) can only be set in the MCE state. So now recording doesn't hang, and data is returned, but the recorded sound doesn't sound right when played back. Anybody have an idea why? --- mss.c.orig Wed Feb 23 11:04:23 2000 +++ mss.c Fri Jan 28 16:18:28 2000 @@ -92,8 +92,6 @@ static int ad_read(struct mss_info *mss, int reg); static voidad_write(struct mss_info *mss, int reg, u_char data); static voidad_write_cnt(struct mss_info *mss, int reg, u_short data -static voidad_enter_MCE(struct mss_info *mss); -static voidad_leave_MCE(struct mss_info *mss); /* io primitives */ static voidconf_wr(struct mss_info *mss, u_char reg, u_char data); @@ -467,9 +465,7 @@ } if (FULL_DUPLEX(mss) mss-bd_id != MD_OPTI931) ad_write(mss, 12, ad_read(mss, 12) | 0x40); /* mode 2 */ - ad_enter_MCE(mss); ad_write(mss, 9, FULL_DUPLEX(mss)? 0 : 4); - ad_leave_MCE(mss); ad_write(mss, 10, 2); /* int enable */ io_wr(mss, MSS_STATUS, 0); /* Clear interrupt status */ /* the following seem required on the CS4232 */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-multimedia" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic #3 (ffs)
which megaraid adapter do you use in this box (hw, fw ver, bios ver,
cntl-m ver)...
i've seen those panics on our old news box when there where errors on
the scsi busses which did not get detected properly. mainly termination
issues *sigh*
/k
Jeroen Ruigrok van der Werven([EMAIL PROTECTED])@Wed, Feb 23, 2000 at 03:36:29PM +0100:
*sigh*
I think I am going to give up my job and become a buddhist monk...
start = 0, len = 2646, fs = /news
panic: ffs_alloccg: map corrupted
Debugger("panic")
Stopped at Debugger+0x35: movb$0,in_Debugger.372
db trace
Debugger(c01e7ee3) at Debugger+0x35
panic(c01f28bf,c01f28a0,0,a56,c1d0d8d4) at panic+0x70
ffs_mapsearch(c1d0d800,ccd49000,5d2a8,1,b) at ffs_mapsearch+0x143
ffs_alloccg(c1da7700,b,5d2a8,400) at ffs_alloccg+0x21a
ffs_hashalloc(c1da7700,b,5d2a8,400,c0194cb8) at ffs_hashalloc+0x23
ffs_alloc(c1da7700,b,5d2a8,400,c1d38280) at ffs_alloc+0xad
ffs_balloc(d8a1ce68,d8a4c200,c1d6a180,3,d8b74ba0) at ffs_balloc+0x456
ffs_write(d8a1cea0,d6299a80,4c,c1d6a180,c0201d00) at ffs_write+0x319
vn_write(c1d6a180,d8a1ceec,c1d38280,0,d6299a80) at vn_write+0xda
dofilewrite(d6299a80,c1d6a180,18,280c4000,4c) at dofilewrite+0x91
write(d6299a80,d8a1cf80,280ad140,280ad140,280c404d) at write+0x33
syscall(280c002f,280a002f,bfbf002f,280c404d,280ad140) at syscall+0x176
Xint0x80_syscall() at Xint0x80_syscall+0x26
--
Jeroen Ruigrok van der Werven Network- and systemadministrator
[EMAIL PROTECTED] bART Internet Services /
BSD: Technical excellence at its best VIA NET.WORKS Netherlands
Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-fs" in the body of the message
--
Hugh Hefner is a virgin.
http://www.webmonster.de http://www.apache.de http://www.splatterworld.de
(NIC-HDL KR433/KR11-RIPE)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Panic #3 (ffs)
-On [2223 20:35], Karsten W. Rohrbach ([EMAIL PROTECTED]) wrote: which megaraid adapter do you use in this box (hw, fw ver, bios ver, cntl-m ver)... i've seen those panics on our old news box when there where errors on the scsi busses which did not get detected properly. mainly termination issues *sigh* amr0: AMI MegaRAID mem 0xe300-0xe300 irq 10 at device 10.1 on pci0 amr0: firmware EH61 bios 1.31 16MB memory amrd0: MegaRAID logical drive on amr0 amrd0: 35040MB (71761920 sectors) RAID 0 (optimal) And I receive the panics on BOTH the array and the normal da disks. I know the termination is correct. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic #3 (ffs) (MegaRAID)
At 08:30 PM 2/23/00 +0100, Karsten W. Rohrbach wrote: which megaraid adapter do you use in this box (hw, fw ver, bios ver, cntl-m ver)... i've seen those panics on our old news box when there where errors on the scsi busses which did not get detected properly. mainly termination issues *sigh* I dont think its necessarily a termination issue. I have swapped the exact same chain onto a Mylex DAC960 and can pound the box without issue. I have a nasty feeling my 466 might not like my MB chipset. I am using a 466 PERC2/SC on BX chipset ECS MB and its throwing all sorts of fits. When I used a 428 on another box (a plain old Pentium), I didnt have nearly this many problems. Soon as my co-worker is finished with the older Pentium, I can test this theory to see if this is the case. Looking at the release notes for the BIOS revs at AMI, it seems older BIOS revs might have problems with newer MBs From ftp://ftp.megatrends.com/MegaRAID/drivers/466/readme-gh6d.txt Changes in this release: --- 1. CTRL-M is not invoked until after the system BIOS is completed on newer systems that support PMM (POST Memory Management). The system would hang at different places in CTRL-M on these systems prior to these changes. Until I flashed it to this new rev, I was seeing this behaviour. ---Mike Mike Tancsa, tel +1 519 651 3400 Network Administrator,[EMAIL PROTECTED] Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of 'device awe' ?
On Tue, Feb 22, 2000 at 04:10:02PM -0800, Andy Sparrow wrote: AFAIK, the AWE cannot work without this, and the cards PnPinfo seems to not include the other two registers - and if you don't probe them, then the 'awe' driver check doesn't see the EMU8000... Is there even a single person out there able to use the AWE device under Voxware in -current? No, but that's sort of moot as far as I'm concerned, since I also can't record sound (see "Creative SB AWE64 recording does not work" on freebsd-current). It comes out as static regardless of the input source. There are just so many things broken right now, I haven't got time to worry about not having sound recording, but it'll be sad if 4.0 is released in this state. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Forgive me if I'm beating a dead horse... I'm still having the following problem if I load any modules from /boot/loader.conf: ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_INTR ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed no devsw (majdev=0 bootdev=0xa040) Mounting root from ufs:/dev/ad0s3a no such device 'ad' setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 If at the boot prompt I: unload load kernel boot there's no problem. Also there's no problem if loading modules from /boot/loader.conf with a kernel suped and built on Feb. 17th with today's buildworld. Mike Smith wrote: it does : I've tried loading miibus alone : works fine loading miibus, then if_xl : loops in loading miibus Ok. We know that hurts, don't do that. 8) From the above remark should I conclude that it's a known problem and we should refrain from loading modules from the boot loader until it works? Or would it help send boot_verbose output from my kernel as well? -- Yarema To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm and /dev/dsp
In 4.0, the pcm sound driver works with my es1371 chipset soundcard for playing cds. But I cannot play mp3s. When I use mpg123, I get the error message "can't open /dev/dsp!" This is an improvement over 3.4, however, where I could not get pcm to work at all. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USA_RESIDENT= in latest current
Even though I have USA_RESIDENT="YES" in /etc/make.conf (this is how it was installed), I get: !! You must define the value of USA_RESIDENT as 'YES' or 'NO' as appropriate, in the environment or /etc/make.conf before building can proceed. !! *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, 23 Feb 2000, Brooks Davis wrote: On Wed, Feb 23, 2000 at 12:15:39PM -0800, R Joseph Wright wrote: In 4.0, the pcm sound driver works with my es1371 chipset soundcard for playing cds. But I cannot play mp3s. When I use mpg123, I get the error message "can't open /dev/dsp!" This is an improvement over 3.4, however, where I could not get pcm to work at all. The first pcm device is now pcm0 not pcm1 for PCI devices. Did you do a "MAKEDEV snd0" after upgrading. My es1371 is working great streaming mp3s off of my.mp3.com using xmms. Beautiful. Thank you :) What about for isa cards? Which one is used for them now? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USA_RESIDENT= in latest current
My make.conf is in /usr/defaults. I'm running 4.0-RC2 on a laptop. I set USA_RESIDENT="YES" there, and it seemed to work fine. Forrest Aldrich wrote: Even though I have USA_RESIDENT="YES" in /etc/make.conf (this is how it was installed), I get: !! You must define the value of USA_RESIDENT as 'YES' or 'NO' as appropriate, in the environment or /etc/make.conf before building can proceed. !! *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- PETER SCHWENK| UNIX System Administrator Department of Mathematical Sciences | University of Delaware [EMAIL PROTECTED]| (302)831-0437 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USA_RESIDENT= in latest current
On Wed, Feb 23, 2000 at 03:25:42PM -0500, Forrest Aldrich wrote: Even though I have USA_RESIDENT="YES" in /etc/make.conf (this is how it was installed), I get: !! You must define the value of USA_RESIDENT as 'YES' or 'NO' as appropriate, in the environment or /etc/make.conf before building can proceed. !! The proper format is USA_RESIDENT= YES in make.conf. -Chris -- [EMAIL PROTECTED] [EMAIL PROTECTED] Abbotsford, BC, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wierd AMD panics caused by VMWare?
:On Wed, 23 Feb 2000, David Gilbert wrote: : :... : : I have half-a-dozen crash dumps of this nature. For me, it always : happens in fdcopy(). This may be due to the fact that the machine is : running a large apache config --- so fork() is something it's doing : often. : :See PR 16568. pmap_remove_all() doesn't flush the TLB properly in :FreeBSD-3.x on i386's. Somehow this doesn't cause many problems, but :it fairly reliably breaks the free() in fdfree() when there was a file :descriptor larger than about 1000 (this gives a free() of more than :MAXALLOCSAVE = 2 pages) when there is a lot of fork() activity. : :Bruce Ahh. I presume you will commit this patch now that Bjoern has confirmed that it works? I don't know why an unconditional invltlb() didn't work either, it should have. Maybe the __asm macro is being optimized out. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux Emulation patches
Hi:
I was wondering who
mantains the Linux Emulation? I have some patches that were sent to me for
FreeBSD-3.4, I have converted them to FreeBSD 4.0-Current for Linux emulation
problems. Specifically anyone trying to use any program that opens a server
socket will get bitten by the emulation unless these patches are applied (
JServ, Resin, Tomcat are some Java programs affected by this... andsince
Sun hasn't release a JDK 1.2 for FreeBSD,well, the only way to run some
server programsis with Blackdown, butwithout these patches they are
useless ).
Anyways, after
sending email to marcel and peter with the patches, I haven't even received a
reply. So therefore, I'm posting them here, in case anyone wants to commit them
at all. I feel 4.0 shouldn't go out with a known broken linux emulation.
---
/usr/src/sys/i386/linux/linux_file.cWed Feb 23 16:11:50 2000+++
/usr/src/sys/i386/linux/linux_file.origWed Feb 23 16:11:37 2000@@
-199,6 +199,12 @@ } */ fcntl_args;
struct linux_flock
linux_flock; struct flock
*bsd_flock;+ struct filedesc *fdp;+
struct file *fp;+ struct vnode *vp;+
long pgid;+ struct pgrp *pgrp;+
struct tty *tp; caddr_t
sg; dev_t dev;@@ -283,9 +289,47
@@ case
LINUX_F_SETOWN: case
LINUX_F_GETOWN:-fcntl_args.cmd = args-cmd == LINUX_F_SETOWN ?
F_SETOWN : F_GETOWN;-fcntl_args.arg = args-arg;-return
fcntl(p, fcntl_args); +/*+ * We need to route around
the normal fcntl() for these calls,+ * since it uses TIOC{G,S}PGRP,
which is too restrictive for+ * Linux F_{G,S}ETOWN semantics. For
sockets, this problem+ * does not exist.+ */+fdp =
p-p_fd;+if ((u_int)args-fd = fdp-fd_nfiles
||+(fp = fdp-fd_ofiles[args-fd]) ==
NULL)+ return EBADF;+if (fp-f_type ==
DTYPE_SOCKET) {+ fcntl_args.cmd = args-cmd ==
LINUX_F_SETOWN ? F_SETOWN : F_GETOWN;+
fcntl_args.arg =
args-arg;+ return fcntl(p, fcntl_args);
+}+vp = (struct vnode *)fp-f_data;+dev =
vn_todev(vp);+if (dev == NODEV)+ return
EINVAL;+if (!(devsw(dev)-d_flags
D_TTY))+ return EINVAL;+tp =
dev-si_tty;+if (!tp)+ return
EINVAL;+if (args-cmd == LINUX_F_GETOWN)
{+ p-p_retval[0] = tp-t_pgrp ?
tp-t_pgrp-pg_id : NO_PID;+ return
0;+}+if ((long)args-arg = 0)
{+ pgid = -(long)args-arg;+} else
{+ struct proc *p1 =
pfind((long)args-arg);+ if (p1 ==
0)+return (ESRCH);+ pgid =
(long)p1-p_pgrp-pg_id;+}+pgrp =
pgfind(pgid);+if (pgrp == NULL || pgrp-pg_session !=
p-p_session)+ return
EPERM;+tp-t_pgrp = pgrp;+return
0; } return
EINVAL;}
---
/usr/src/sys/i386/linux/linux_socket.cWed Feb 23 16:11:50 2000+++
/usr/src/sys/i386/linux/linux_socket.origWed Feb 23 16:11:48 2000@@
-441,11 +441,6 @@caddr_t name;int
*anamelen; } */ bsd_args;-
struct fcntl_args /* {- int fd;- int
cmd;- long arg;- } */
f_args; int
error; if ((error=copyin((caddr_t)args,
(caddr_t)linux_args, sizeof(linux_args@@ -453,24 +448,7
@@ bsd_args.s =
linux_args.s; bsd_args.name =
(caddr_t)linux_args.addr; bsd_args.anamelen =
linux_args.namelen;-- if (error = oaccept(p,
bsd_args))-return error;-
/*- * linux appears not to copy flags from the
parent socket to the- * accepted one, so we must
clear the flags in the new descriptor.-
*/- f_args.fd = p-p_retval[0];-
f_args.cmd = F_SETFL;- f_args.arg = 0;-
/*- * we ignore errors here since otherwise we would
have an open file- * descriptor that wasn't returned
to the user.- */- (void)
fcntl(p, f_args);- /* put the file descriptor back as
the return value */- p-p_retval[0] =
f_args.fd;- return 0;+ return
oaccept(p, bsd_args);}struct
linux_getsockname_args {
Re: Union semun defined in /usr/include/sys/sem.h?
On 2000-Feb-23 23:46:35 +1100, Brad Knowles [EMAIL PROTECTED] wrote: However, this has brought up an interesting question. It is my understanding that X/Open requires that this union be defined within the client source code Both Solaris and the Single UNIX Specification, Version 2 explicitly state this. Is this changed in -CURRENT? Not at present. If not, are there any plans to change it in -CURRENT? Or has the X/Open standard changed, and FreeBSD is following the new standard in this area? I can't comment on this. There doesn't seem to be a high level of interest in the SysV semaphore handling. I'm also curious to know why there is a difference in how this object is defined under Linux and FreeBSD. There are two differences: - The type of "array": SUSv2 and Linux specify "unsigned short int *", Solaris uses "ushort *" and FreeBSD uses "u_short *". The underlying type should be the same. (Though it does bring up another `bug' in our implementation - SUSv2 states sys/sem.h should be idempotent, but we require sys/types.h to be explicitly included first). - Linux includes an "__buf" field. This field (and the associated IPC_INFO) don't appear in either SUSv2 or Solaris - I suspect it is a Linux extension to make ipcs(1) cleaner. However, I'm also interested as to who is "right" on this issue, and more importantly, why they are "right". It looks very much like FreeBSD is in the wrong here. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
The first pcm device is now pcm0 not pcm1 for PCI devices. Did you do a "MAKEDEV snd0" after upgrading. My es1371 is working great streaming mp3s off of my.mp3.com using xmms. Beautiful. Thank you :) What about for isa cards? Which one is used for them now? See the output of dmesgt for the pcm[0-9] device that attaches to it. Then check what the /dev/ entries say. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, Feb 23, 2000 at 12:27:49PM -0800, R Joseph Wright wrote: Beautiful. Thank you :) What about for isa cards? Which one is used for them now? I gave my only ISA sound card to Camran so I can't say for sure, but if you hardware the probe address the card ends up at that number and I think PnP cards would end up at pcm0 by default. However, Nick gave the more correct answer in that you should check dmesg and /dev/sndstat. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Wierd AMD panics caused by VMWare?
I have gathered a bit more information. The problem I'm having always ends up in the same place - line 403 of vfs_cache.c. No matter how I try and test the value of ncpp before starting the inner for() (which bombs dereferencing NULL in the init part), I end up getting traps with ncpp being NULL, which is one of those can't-possibly-happen things. 1. I have found that putting an if (panicstr) return ; at the top of this routine necessary. When the trap happens, usually it ends up causing a circular panic. 2. I went through this routine's parent (in the panic), dounmount(). One of the things I discovered is that the clearing of the name cache (what cache_purgevfs() does, I guess) happens very early in an unmount. This means that I can put "unmount /usr" in a loop, and even though the unmount will always fail, it will end up making the namei cache useless. Now, It'd be sort of dopey to do this, I'll admit, but aparently it's the sort of thing amd does fairly routinely (it must blindly attempt to unmount every partition and the ones that don't go away must be in use). This probably has an impact on the namei cache efficiency of amd mounted disks. :-) 3. unmount /usr is sufficient to cause the panic, but not all of the time. Something has to happen to set up a situation where the unmount attempt will cause the trap. 4. My latest attempt has been to change ncpp from a stack variable to a global (staticly declared in vfs_cache.c). This _appears_ to be working longer than previous attempts, but just about every time I say that it seems it croaks almost immediately. :-) It's a bit of a gross workaround for an aparent register corruption (ddb shows that the instruction that fails is a movl 0(%eax),%eamumble). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USA_RESIDENT= in latest current
Perhaps, but take a look at the installation... it sets it to USA_RESIDENT="YES" (note WITH quotes). _F The proper format is USA_RESIDENT= YES in make.conf. -Chris -- [EMAIL PROTECTED] [EMAIL PROTECTED] Abbotsford, BC, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 buildworld breaking
On Wed, 23 Feb 2000, Doug Barton wrote: Mark Russell wrote: Hi For the last few days I've been trying to buildworld on my -CURRENT box and it barfs at libperl. cc -O -pipe -I/usr/obj/usr/src/gnu/usr.bin/perl/libperl -I/usr/src/gnu/usr.bin/perl/libperl/../../../../contrib/perl5 -I/usr/obj/usr/src/i386/usr/include -c /usr/src/gnu/usr.bin/perl/libperl/../../../../contrib/perl5/toke.c -o toke.o mkdir: build: File exists *** Error code 1 You should discuss -current problems on freebsd-current. This looks like a Wrist slap taken. classic "stale dependencies" problem. Try deleting /usr/obj/* and /usr/src/*, download new sources and try again. OK Now I'm even more baffled, I hosed /usr/obj and /usr/src and it broke in exactly the same place. Just wondering if you anyone else had any more idea's? Thanx +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Mark Russell [EMAIL PROTECTED] ph 61 + 2 + 9699 3837 viper.net.au http://www.viper.net.au fax 61 + 2 + 9699 3841 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Would you let this organisation make judgements about you http://www.tio.sux.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sync hang
I'm full of all sorts of good news today. :-( The machine I'm having such problems with just hung. Fortunately, I was able to get at it with ddb and force it to dump. The resulting core gives me this stack trace: #8 0xc026bde7 in siointr (arg=0xc0afe000) at ../../isa/sio.c:1679 #9 0xc0250b37 in Xfastintr4 () #10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at ../../kern/vfs_default.c:138 #11 0xc01d1023 in nfs_sync (mp=0xc0bc7200, waitfor=3, cred=0xc073b780, p=0xc84b7780) at vnode_if.h:27 #12 0xc0181571 in sync_fsync (ap=0xc84c5f7c) at ../../kern/vfs_subr.c:2827 #13 0xc017faf7 in sched_sync () at vnode_if.h:537 From 9 on up it is undoubtedly the result of the drop into DDB and the subsequent dump and boot. A ps on the core shows that indeed, the syncer is the running "process". vop_default() is very short, but there's no stack entry from VOCALL(). Perhaps it "wandered off..."? vmware was booting NT4 at the time. I'm begining to think that vmware isn't ready for prime time, but I can't quite come up with a mechanism in my head for how it's causing this and that I am somehow the only person in the world seeing it. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic (pmap)
On Wed, Feb 23, 2000 at 09:25:12AM -0800, Matthew Dillon wrote: Looks like Ian has tracked down our problem, but that's unlikely to be the problem Jurgen is seeing. I think it may be worth having David do a quick patch to see if it helps. David, try the following brute-force patch and see if it helps. Is this likely to help him? Also, is this an SMP box or not? Just for reference, it wasn't. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, 23 Feb 2000, Brooks Davis wrote: On Wed, Feb 23, 2000 at 12:27:49PM -0800, R Joseph Wright wrote: Beautiful. Thank you :) What about for isa cards? Which one is used for them now? I gave my only ISA sound card to Camran so I can't say for sure, but if you hardware the probe address the card ends up at that number and I think PnP cards would end up at pcm0 by default. However, Nick gave the more correct answer in that you should check dmesg and /dev/sndstat. I actually do not have an isa sound card, I was merely curious because in 3.x, pcm0 was reserved for isa cards and pcm1 was used for pci. Is it now set up so that it doesn't matter whether the card is isa or pci, you just use pcm0? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[Fwd: sync hang]
Oh... one more thing on the hang... (kgdb) #10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at ../../kern/vfs_default.c:138 138 return (VOCALL(default_vnodeop_p, ap-a_desc-vdesc_offset, ap)); (kgdb) print ap $3 = (struct vop_generic_args *) 0x0 if ap is NULL, then ap-a_desc-vdesc_offset is probably a bad idea. :-( Looking at the actual disassembly, it looks like another case of a register getting a 0 stuffed into it at the oddest of times. I'm full of all sorts of good news today. :-( The machine I'm having such problems with just hung. Fortunately, I was able to get at it with ddb and force it to dump. The resulting core gives me this stack trace: #8 0xc026bde7 in siointr (arg=0xc0afe000) at ../../isa/sio.c:1679 #9 0xc0250b37 in Xfastintr4 () #10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at ../../kern/vfs_default.c:138 #11 0xc01d1023 in nfs_sync (mp=0xc0bc7200, waitfor=3, cred=0xc073b780, p=0xc84b7780) at vnode_if.h:27 #12 0xc0181571 in sync_fsync (ap=0xc84c5f7c) at ../../kern/vfs_subr.c:2827 #13 0xc017faf7 in sched_sync () at vnode_if.h:537 From 9 on up it is undoubtedly the result of the drop into DDB and the subsequent dump and boot. A ps on the core shows that indeed, the syncer is the running "process". vop_default() is very short, but there's no stack entry from VOCALL(). Perhaps it "wandered off..."? vmware was booting NT4 at the time. I'm begining to think that vmware isn't ready for prime time, but I can't quite come up with a mechanism in my head for how it's causing this and that I am somehow the only person in the world seeing it. :-)
Re: Linux Emulation patches
On Wed, 23 Feb 2000, Victor A. Salaman wrote: Anyways, after sending email to marcel and peter with the patches, I haven't even received a reply. :-( So therefore, I'm posting them here, in case anyone wants to commit them at all. I feel 4.0 shouldn't go out with a known broken linux emulation. One way to make sure your patch does not get lost is to create a GNATS report with the patch and priority=high by means of send-pr or the web form at http://www.freebsd.org/support.html#gnats. Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm and /dev/dsp
On Wed, Feb 23, 2000 at 03:26:07PM -0800, R Joseph Wright wrote: On Wed, 23 Feb 2000, Brooks Davis wrote: On Wed, Feb 23, 2000 at 12:27:49PM -0800, R Joseph Wright wrote: Beautiful. Thank you :) What about for isa cards? Which one is used for them now? I gave my only ISA sound card to Camran so I can't say for sure, but if you hardware the probe address the card ends up at that number and I think PnP cards would end up at pcm0 by default. However, Nick gave the more correct answer in that you should check dmesg and /dev/sndstat. I actually do not have an isa sound card, I was merely curious because in 3.x, pcm0 was reserved for isa cards and pcm1 was used for pci. Is it now set up so that it doesn't matter whether the card is isa or pci, you just use pcm0? Basicaly, yes. The current system avoids skipping numbers where the old one would skip entries where you had provided isa probe hints, but there wasn't a card there. I believe there was some talk about changing things so device hints mean something like, "if there is a device matching these parameters use this entry, otherwise, don't." This would allow things like wiring devices to slots on PCI. It is possiably I misunderstood the proposal and it certaintly won't make it into 4.0. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BIOS and PERC 2/SC (was Re: Perc 2/SC problems (aka MegaRAID 466) )
At 09:19 PM 2/22/2000 -0800, Mike Smith wrote: On 18 Feb 2000 17:39:19 -0500, in sentex.lists.freebsd.current you wrote: Hmm. I did some testing, and I can lock both the G6HC and G6HD firmware up within a few minutes. The Dell 3.00 firmware remains stable under the same load (20 simultaneous 'bonnie -s 100's). I'm fairly sure it's a firmware lockup - the SCSI bus is hung and usually the PCI bus as well. I am going to test the card in another older MB to see if its some strange interaction. What MB chipset are you using to test with ? I've been testing most recently with the Intel 450NX and AMD 751. OK, on the PERC2/SC and LINUX with the firmware from Dell (3.00), it pukes with Redhat LINUX. I am able to talk to the card, fdisk and newfs it, but it crashes hard when you write to the partition. I am going to try and reflash the card to the latest AMI BIOS and see what happens. ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sync hang
:I'm full of all sorts of good news today. :-( : :The machine I'm having such problems with just hung. Fortunately, I was :able to get at it with :ddb and force it to dump. The resulting core gives me this stack trace: What kind of machine is this? 3.x or 4.x? This could be another pmap issue but I doubt it. I think it's time for me to install VMWare :-) The process may not be 'stuck' in vop_defaultop ... it may be in an infinite loop at a higher level instead (e.g. in sync_fsync() or nfs_sync()). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree86 3.9.18
I've built this thing on -current recently, and I'l getting the weirdest errors when I try to start X: (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 3 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 9 Elf_RelocateEntry() Unsupported relocation type 9 - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ffs_blkfree: freeing free block (was Re: Panic (pmap))
In message [EMAIL PROTECTED], Ian Dowse writes:
The fix should be relatively straightforward - either the code should
avoid linking new indirection blocks until all allocations succeed,
or it should back out the changes on failure.
Here's one patch that seems to fix the problem. It may not be the best
approach though?
Ian
--- ffs_balloc.c.orig Thu Feb 24 00:44:32 2000
+++ ffs_balloc.cThu Feb 24 01:45:46 2000
@@ -71,7 +71,7 @@
int flags;
struct fs *fs;
ufs_daddr_t nb;
- struct buf *bp, *nbp;
+ struct buf *bp, *nbp, *allocbp;
struct vnode *vp;
struct indir indirs[NIADDR + 2];
ufs_daddr_t newb, *bap, pref;
@@ -197,6 +197,7 @@
--num;
nb = ip-i_ib[indirs[0].in_off];
allocib = NULL;
+ allocbp = NULL;
allocblk = allociblk;
if (nb == 0) {
pref = ffs_blkpref(ip, lbn, 0, (ufs_daddr_t *)0);
@@ -272,6 +273,17 @@
}
}
bap[indirs[i - 1].in_off] = nb;
+ if (allocib == NULL) {
+ /*
+* Writing bp would link in the newly allocated
+* blocks; hold off in case of allocation failure
+* later.
+*/
+ allocib = bap[indirs[i - 1].in_off];
+ allocbp = bp;
+ continue;
+ }
+
/*
* If required, write synchronously, otherwise use
* delayed write.
@@ -316,8 +328,7 @@
bp-b_flags |= B_CLUSTEROK;
bdwrite(bp);
}
- *ap-a_bpp = nbp;
- return (0);
+ goto success;
}
brelse(bp);
if (flags B_CLRBUF) {
@@ -330,6 +341,22 @@
nbp = getblk(vp, lbn, fs-fs_bsize, 0, 0);
nbp-b_blkno = fsbtodb(fs, nb);
}
+success:
+ if (allocbp != NULL) {
+ /*
+* It is safe to write allocbp now.
+*
+* If required, write synchronously, otherwise use
+* delayed write.
+*/
+ if (flags B_SYNC) {
+ bwrite(allocbp);
+ } else {
+ if (allocbp-b_bufsize == fs-fs_bsize)
+ allocbp-b_flags |= B_CLUSTEROK;
+ bdwrite(allocbp);
+ }
+ }
*ap-a_bpp = nbp;
return (0);
fail:
@@ -349,8 +376,11 @@
ffs_blkfree(ip, *blkp, fs-fs_bsize);
deallocated += fs-fs_bsize;
}
- if (allocib != NULL)
+ if (allocib != NULL) {
*allocib = 0;
+ if (allocbp != NULL)
+ brelse(allocbp);
+ }
if (deallocated) {
#ifdef QUOTA
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ffs_blkfree: freeing free block (was Re: Panic (pmap))
:I think I've found it. Here's an easy way to repeat the problem to
:start with:
:
: mount_mfs -T fd1440 none /mnt
: cd /mnt
: dd if=/dev/zero bs=4k of=test seek=1036 count=1
: dd if=/dev/zero bs=4k of=test1 count=1
: dd if=/dev/zero bs=4k of=test2
: rm test1
: dd if=/dev/zero bs=4k of=test seek=8000 count=1
: echo test
:
:It looks as if the problem is in ffs_balloc(), and occurs as follows:
: - ffs_balloc() is asked to allocate a doubly indirect block.
: - The first-level indirection block already exists
: - The second-level indirection block does not exist, but is
: successfully allocated.
: - This block is linked into the first-level indirection block by
: the line:
:
: bap[indirs[i - 1].in_off] = nb;
:
: - Allocation of the data block fails.
: - All allocated blocks are then released, but there is still
: a link in the first-level indirection block to what is
: now a free block.
:
:The fix should be relatively straightforward - either the code should
:avoid linking new indirection blocks until all allocations succeed,
:or it should back out the changes on failure.
:
:Ian
Great detective work! The 'allocib' variable is used to unwind the
'first' new indirect block allocation, but it is *only* initialized
for the Level 0 block. So the unwinding only works when the Level 0
indirect block had to be allocated. When the Level 0 indirect block
is valid and a deeper level indirect block had to be allocated,
allocib is not initialized and the association is not unwound even
though the deeper indirect block is freed when the data block allocation
fails.
Unfortunately, we can't simply initialize 'allocib' here, because it
would point into the middle of a buffer. The fix is thus not entirely
trivial.
This is what I think we need to do, but THIS PATCH IS NOT TESTED AND
COULD BE COMPLETELY WRONG. Any filesystem gurus out there who can look
at this and tell me if it's correct?
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: ffs_balloc.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_balloc.c,v
retrieving revision 1.25
diff -u -r1.25 ffs_balloc.c
--- ffs_balloc.c2000/01/11 08:27:00 1.25
+++ ffs_balloc.c2000/02/24 02:25:53
@@ -77,6 +77,7 @@
ufs_daddr_t newb, *bap, pref;
int deallocated, osize, nsize, num, i, error;
ufs_daddr_t *allocib, *blkp, *allocblk, allociblk[NIADDR + 1];
+ int unwindidx = -1;
struct proc *p = curproc; /* XXX */
vp = ap-a_vp;
@@ -272,6 +273,8 @@
}
}
bap[indirs[i - 1].in_off] = nb;
+ if (allocib == NULL unwindidx 0)
+ unwindidx = i - 1;
/*
* If required, write synchronously, otherwise use
* delayed write.
@@ -349,8 +352,26 @@
ffs_blkfree(ip, *blkp, fs-fs_bsize);
deallocated += fs-fs_bsize;
}
- if (allocib != NULL)
+ if (allocib != NULL) {
*allocib = 0;
+ } else if (unwindidx = 0) {
+ error = bread(vp,
+ indirs[unwindidx].in_lbn, (int)fs-fs_bsize, NOCRED, bp);
+ if (error) {
+ panic("Could not unwind indirect block, error %d", error);
+ brelse(bp);
+ } else {
+ bap = (ufs_daddr_t *)bp-b_data;
+ bap[indirs[unwindidx].in_off] = 0;
+ if (flags B_SYNC) {
+ bwrite(bp);
+ } else {
+ if (bp-b_bufsize == fs-fs_bsize)
+ bp-b_flags |= B_CLUSTEROK;
+ bdwrite(bp);
+ }
+ }
+ }
if (deallocated) {
#ifdef QUOTA
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 3.9.18
On Wed, 23 Feb 2000, Kenneth Wayne Culver wrote: That's odd... I just built it tonight, and I havn't had anything but this: XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 Which doesn't cause the server to crash, in fact, it seems pretty stable. What did you put in your host.def? Here's my host.def (see attachment). - Donn XCOMM $XFree86: xc/config/cf/xf86site.def,v 3.153 1999/12/03 19:17:17 eich Exp $ /**/ /* * This file is to provide a quick method for most people to change the * behaviour of their XFree86 installation without having to fully * understand the workings of site.def and all the various '.cf' files. * * These are the most common settings you would choose for compiling and * installing XFree86 on the systems supported by it. * * A good way to use this file is to copy it to host.def, and make the * changes there. That way, future patches to this file won't fail. * The host.def file will never be patched. * * The distributed version of this file should contain no uncommented * definitions. Such default definitions belong in xfree86.cf. */ /**/ /* * If you have build-specific modifications in your host.def file, but * want an empty host.def file installed when doing 'make install', * uncomment the following * #define InstallEmptyHostDef */ /* * If using GCC 2.x on a system where it isn't the default, uncomment * the following * #define HasGcc2 YES #define HasGcc YES */ /* * If using GCC 2.x with C++ on a system where it isn't the default, uncomment * the following. * #define HasGcc2ForCplusplus YES */ /* * The default optimisation flags for GCC 2.x. -fno-strength-reduce is * here to work around a bug in -O2 for GCC 2.x on i386 platforms. * If you are using a version that doesn't have this bug, you can * uncomment the following line, and remove '-fno-strength-reduce' * If you are building binaries for a 486, it may be beneficial to add * -m486 * */ #define DefaultGcc2i386Opt -mpentium -O3 -pipe /* * This allows the GCC warning flags to be set. The default is shown here. * */ #define GccWarningOptions -Wall /* * Sun Compiler stuff.. * #define HasSunC YES #define HasSunCplusplus YES #define CplusplusCompilerMajorVersion 5 #define CplusplusCompilerMinorVersion 0 #define CCompilerMajorVersion 5 #define CCompilerMinorVersion 0 */ /* * Optimized Sun Compiler Build. * #define DefaultCDebugFlags -xO4 -xtarget=pentium_pro #define OptimizedCDebugFlags-xO4 -xtarget=pentium_pro */ /* * Debuggable Sun Compiler Build. * Note: This builds _EVERYTHING_ as debuggable * #define DefaultCDebugFlags -g -xs #define OptimizedCDebugFlags-g -xs */ /* * For Linux, this should match the Binutils version you have. This example * is for 2.6.0.7. See linux.cf for the default setting. * * This should automatically get set correctly by imake. * #define LinuxBinUtilsMajorVersion 26 */ /* * For Linux, these should match the libc version you have. This example * is for libc.5.4.x. See linux.cf for the default setting. * * This should automatically get set correctly by imake. * #define LinuxCLibMajorVersion 5 #define LinuxClibMinorVersion 4 */ /* * If you want to use the GNU malloc library, uncomment this * #define UseGnuMallocYES */ /* * Set this to whatever is required to access the GNU malloc library. * The default is '-lgmalloc' unless is specified in the OS's .cf file. * #define GnuMallocLibrary-L/usr/local/lib -lgmalloc */ /* * To disable the internal Xserver malloc, set this to NO * #define UseInternalMalloc YES */ /* * Some Linux releases don't have a libtermcap. In this case you may need * to uncomment the following * #define TermcapLibrary -lncurses */ /* * If you have Tk (which is required to build XF86Setup), uncomment this * Note: version 4.0 or 4.1 is required, and XF86Setup links it statically by * default. * #define HasTk YES */ /* * Set the paths and names for your Tk library if they don't match the * defaults (check your OS .cf file or Imake.tmpl for the defaults). * * Common values
Re: XFree86 3.9.18
That's odd... I just built it tonight, and I havn't had anything but this: XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 Which doesn't cause the server to crash, in fact, it seems pretty stable. 24 EMFILE Too many open files. As released, the limit on the number of open files per process is 64. Getdtablesize(2) will obtain the current limit. You can probably bump up your ulimit, and make this go away, too. Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ffs_blkfree: freeing free block (was Re: Panic (pmap))
Ian's test script
mount_mfs -T fd1440 none /mnt
cd /mnt
dd if=/dev/zero bs=4k of=test seek=1036 count=1
dd if=/dev/zero bs=4k of=test1 count=1
dd if=/dev/zero bs=4k of=test2
rm test1
dd if=/dev/zero bs=4k of=test seek=8000 count=1
echo test
Oops, here's a new version of my patch. This one survives Ian's test
script. I was improperly blowing away an 'error' field.
-Matt
Index: ffs_balloc.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_balloc.c,v
retrieving revision 1.25
diff -u -r1.25 ffs_balloc.c
--- ffs_balloc.c2000/01/11 08:27:00 1.25
+++ ffs_balloc.c2000/02/24 05:44:59
@@ -77,6 +77,7 @@
ufs_daddr_t newb, *bap, pref;
int deallocated, osize, nsize, num, i, error;
ufs_daddr_t *allocib, *blkp, *allocblk, allociblk[NIADDR + 1];
+ int unwindidx = -1;
struct proc *p = curproc; /* XXX */
vp = ap-a_vp;
@@ -272,6 +273,8 @@
}
}
bap[indirs[i - 1].in_off] = nb;
+ if (allocib == NULL unwindidx 0)
+ unwindidx = i - 1;
/*
* If required, write synchronously, otherwise use
* delayed write.
@@ -349,8 +352,28 @@
ffs_blkfree(ip, *blkp, fs-fs_bsize);
deallocated += fs-fs_bsize;
}
- if (allocib != NULL)
+ if (allocib != NULL) {
*allocib = 0;
+ } else if (unwindidx = 0) {
+ int r;
+
+ r = bread(vp, indirs[unwindidx].in_lbn,
+ (int)fs-fs_bsize, NOCRED, bp);
+ if (r) {
+ panic("Could not unwind indirect block, error %d", error);
+ brelse(bp);
+ } else {
+ bap = (ufs_daddr_t *)bp-b_data;
+ bap[indirs[unwindidx].in_off] = 0;
+ if (flags B_SYNC) {
+ bwrite(bp);
+ } else {
+ if (bp-b_bufsize == fs-fs_bsize)
+ bp-b_flags |= B_CLUSTEROK;
+ bdwrite(bp);
+ }
+ }
+ }
if (deallocated) {
#ifdef QUOTA
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ffs_blkfree: freeing free block (was Re: Panic (pmap))
Er, shouldn't you guys let Kirk know, not only is he "MAINTAINER", but
pretty much mostly "CREATOR" :)
Kirk, another issue with running out of space in FFS seems to have
come up:
* Matthew Dillon [EMAIL PROTECTED] [000223 18:57] wrote:
:Ian Dowse [EMAIL PROTECTED] wrote:
:I think I've found it. Here's an easy way to repeat the problem to
:start with:
:
: mount_mfs -T fd1440 none /mnt
: cd /mnt
: dd if=/dev/zero bs=4k of=test seek=1036 count=1
: dd if=/dev/zero bs=4k of=test1 count=1
: dd if=/dev/zero bs=4k of=test2
: rm test1
: dd if=/dev/zero bs=4k of=test seek=8000 count=1
: echo test
:
:It looks as if the problem is in ffs_balloc(), and occurs as follows:
: - ffs_balloc() is asked to allocate a doubly indirect block.
: - The first-level indirection block already exists
: - The second-level indirection block does not exist, but is
: successfully allocated.
: - This block is linked into the first-level indirection block by
: the line:
:
: bap[indirs[i - 1].in_off] = nb;
:
: - Allocation of the data block fails.
: - All allocated blocks are then released, but there is still
: a link in the first-level indirection block to what is
: now a free block.
:
:The fix should be relatively straightforward - either the code should
:avoid linking new indirection blocks until all allocations succeed,
:or it should back out the changes on failure.
:
:Ian
Great detective work! The 'allocib' variable is used to unwind the
'first' new indirect block allocation, but it is *only* initialized
for the Level 0 block. So the unwinding only works when the Level 0
indirect block had to be allocated. When the Level 0 indirect block
is valid and a deeper level indirect block had to be allocated,
allocib is not initialized and the association is not unwound even
though the deeper indirect block is freed when the data block allocation
fails.
Unfortunately, we can't simply initialize 'allocib' here, because it
would point into the middle of a buffer. The fix is thus not entirely
trivial.
This is what I think we need to do, but THIS PATCH IS NOT TESTED AND
COULD BE COMPLETELY WRONG. Any filesystem gurus out there who can look
at this and tell me if it's correct?
[patch snipped, Matt just re-issued a fixed version]
* Matthew Dillon [EMAIL PROTECTED] [000223 22:26] wrote:
Oops, here's a new version of my patch. This one survives Ian's test
script. I was improperly blowing away an 'error' field.
-Matt
Index: ffs_balloc.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_balloc.c,v
retrieving revision 1.25
diff -u -r1.25 ffs_balloc.c
--- ffs_balloc.c 2000/01/11 08:27:00 1.25
+++ ffs_balloc.c 2000/02/24 05:44:59
@@ -77,6 +77,7 @@
ufs_daddr_t newb, *bap, pref;
int deallocated, osize, nsize, num, i, error;
ufs_daddr_t *allocib, *blkp, *allocblk, allociblk[NIADDR + 1];
+ int unwindidx = -1;
struct proc *p = curproc; /* XXX */
vp = ap-a_vp;
@@ -272,6 +273,8 @@
}
}
bap[indirs[i - 1].in_off] = nb;
+ if (allocib == NULL unwindidx 0)
+ unwindidx = i - 1;
/*
* If required, write synchronously, otherwise use
* delayed write.
@@ -349,8 +352,28 @@
ffs_blkfree(ip, *blkp, fs-fs_bsize);
deallocated += fs-fs_bsize;
}
- if (allocib != NULL)
+ if (allocib != NULL) {
*allocib = 0;
+ } else if (unwindidx = 0) {
+ int r;
+
+ r = bread(vp, indirs[unwindidx].in_lbn,
+ (int)fs-fs_bsize, NOCRED, bp);
+ if (r) {
+ panic("Could not unwind indirect block, error %d", error);
+ brelse(bp);
+ } else {
+ bap = (ufs_daddr_t *)bp-b_data;
+ bap[indirs[unwindidx].in_off] = 0;
+ if (flags B_SYNC) {
+ bwrite(bp);
+ } else {
+ if (bp-b_bufsize == fs-fs_bsize)
+ bp-b_flags |= B_CLUSTEROK;
+ bdwrite(bp);
+ }
+ }
+ }
if (deallocated) {
#ifdef QUOTA
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Heads up! OpenSSH is about to enter the tree.
Since it came down to making openssl actually useful for something or taking it out of the tree, we accelerated progress somewhat on the openssh integration work. This is using the rsarefglue stubs I've been talking about for the last couple of days to "abstract" rsaref away so we don't have any RSA bundling issues. Users can load the appropriate rsaref package (or install the port) and openssl-using packages like openssh will then "just work." This work will take place in 3 stages: 1. Mark Murray will bring his openssh work into -current. 2. A lot of fur will fly around while a few things are tweaked. 3. John Polstra and others will work on integrating changes for the static compilation case. Dynamic linking of rsaref works fine, dealing with static linking requires a bit more finesse and we've already worked out what we need to do for this step. I will also be delaying -current's release date until March 10th in order to give this more proper testing. Yes, I know this is a rather stunning development for a code base supposedly in code freeze, but special situations sometimes merit special dispensation and this is one such situation. I think the merits of having ssh in the base system far outweigh the risks of bringing it in right now and I'll be fully supporting this work in a number of ways intended to minimize those risks even further. It's my neck and I'm sticking it out. :) Watch this space, - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: NETGRAPH patches (proposal)
From: Archie Cobbs [mailto:[EMAIL PROTECTED]] Julian Elischer writes: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? Now I think you are talking a separate node that implements such a protocol. Right.. ARP is an IP-specific protocol. Ethernet nodes should have no specific knowledge of ARP. [...] This brings up another point.. to really do this correctly we would also need a 802.3/802.2 node type that decoded Ethertypes and SNAP headers. It would have a "downstream" hook that connected to the Ethernet node and also hooks for "ip", "arp", "appletalk", "aarp" (AppleTalk's ARP), "ipx", "ipv6", etc. Also, it could suport generic Ethertype hooks having names of the form "0x". Probably the raw Ethernet node type should not even know about 802.3 (the standard 14 byte Ethernet header and the 60 byte minimum packet length).. i think that ethernet driver should be just raw ethernet node. it should not have any specific knowledge about upper levels. these raw nodes connected to another node that will perform the same functionality as ``ether_input'' does. i.e. it will decode type and send data to the appropriate hook. if the hook is connected - fine, we got data and put it to the protocol stack. if not - just drop. so we are really control the system. if we need specific protocol in the stack just load specific node and connect it to the hook. we can use simple name convention for the hooks (like "ether_0xNNN" where NNN is type) and in this case we do not have to change ``ether_input'' node. this looks more and more like STREAMS :). but NETGRAPH do not put data in the ``envelope'' like STREAMS does. the only thing that bothers me... how we can marry existing functionality and NETGRAPH? i vote for NETGRAPH :) it is c00l :) i just like the idea of connecting raw ethernet device driver with tty level :) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NETGRAPH patches (proposal)
On Tue, Feb 22, 2000 at 09:02:43PM -0800, Archie Cobbs wrote: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: NETGRAPH patches (proposal) CONT.
On Tue, Feb 22, 2000 at 09:02:43PM -0800, Archie Cobbs wrote: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? i added new control message for ``ngether_node''. i called it NGEF_RAW_MODE. now you can set it to on/off by using NgSendMsg. ``ngether_rcvdata'' will not update ``ether_shost'' if it set to on. otherwise it will. patches available at http://home.earthlink.net/~evmax/ng.tar.gz these are against -current cvsup'ed this sunday around 8:30pm EST. it also includes small test program based ion ``nghook''. Thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NETGRAPH patches (proposal)
David Malone wrote: On Tue, Feb 22, 2000 at 09:02:43PM -0800, Archie Cobbs wrote: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? Now I think you are talking a separate node that implements such a protocol. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NETGRAPH patches (proposal)
Julian Elischer writes: It's because all packets sent by this node should have the node's address. If you don't have it then PPPoE cannot send a packet "FROM" thia node, as it has no idea of what this node's address is. So.. we can have two hooks, one that sets the host address and one that doesn't.. :-) In that case can we have one that also sets the destination address via arp? Now I think you are talking a separate node that implements such a protocol. Right.. ARP is an IP-specific protocol. Ethernet nodes should have no specific knowledge of ARP. But it would be easy to create an ARP node that sat between the IP stack and an Ethernet node... it would maintain an ARP cache, and when it saw an outgoing dest IP address that was unmapped would issue an ARP request, etc. It would listen to the incoming Ethertypes for IP and ARP coming up from the Ethernet node. This brings up another point.. to really do this correctly we would also need a 802.3/802.2 node type that decoded Ethertypes and SNAP headers. It would have a "downstream" hook that connected to the Ethernet node and also hooks for "ip", "arp", "appletalk", "aarp" (AppleTalk's ARP), "ipx", "ipv6", etc. Also, it could suport generic Ethertype hooks having names of the form "0x". Probably the raw Ethernet node type should not even know about 802.3 (the standard 14 byte Ethernet header and the 60 byte minimum packet length).. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
