Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: you don't under stand, we are NOT talking about upgrades, we are talking about how to make a buildable system on -stable... the make buildworld -DNOTOOLS does not work, and will not work for what I like to do.. I need tools from -current that RUN ON -stable... I do understand. You would have known if you followed the other threads on this topic. you completely cut the whole part of me agreeing w/ Peter about -DACIENTTOOLS... and so you know, (this is unrelated to the -current tools running on -stable), you can't do a buildworld w/ -DNOTOOLS and have it succeed: I haven't had time to read is suggestion, contemplate and determine its strengths and weaknesses for myself. If everybody stopped whining for a minute ;-) === libgcc echo '#include i386/xm-i386.h' config.h echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -nostdinc -O -pipe -pipe -O -pipe -O -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c cc1: Invalid option `-fexceptions' *** Error code 1 Mine has stopped at exactly the same point. I started a make world yesterday (it finished tonight). it took me all of 21 minutes for the buildworld to fail.. considering I'm not running softupdates, it'd be even faster... Congratulations! As for me, I'm trying to define the problem as detailed and consise as possible. I already have some specific thoughts and ideas. I'm thinking large here: real cross-compilation capabilities and such (it may be handy for FreeBSD/IA64)... ok, the problem is: a) -current tools are built w/ -current libc and friends Yes. This can't be done. b) -current libc and friends are NOW (they used to not be this way) unable to run on anything but -current because of the signal changes.. We have never supported running -current binaries (ie compiled against a -current environment) to run on -stable. If it worked in the past, nice. c) the problem is that the signal changes do not provide a way to continue to function in the case that the kernel doesn't support the new syscalls... No that's not the real problem here. You're redefining the problem to match your solution. we have a catch-22 in the build environment.. the tools need a -current libc and friends, and libc and friends needs a -current kernel, and a -current kernel needs the tools to be built... No, we don't have a catch-22. We're using the wrong sources for the wrong reasons. the solution is to make libc and friends be able to operate on a non-current system by wrapping the signal stuff in #ifdef's that will provide fall back support when requested and use the o* syscalls in this case... That may solve this problem, but doesn't leave you with cross-compilation. what we may want to do, is to leave the old signal code in, and simply add in the ability to "select" what signal code we want to include.. and make it a general system so that it just doesn't apply to the signal system... I can't parse this. The old sisgnal code hasn't been removed. We have to explicitly add support, because we need to transform the new sigset_t related calls onto the old. this way we can say, we are building under NetBSD, and they don't have getcwd as a syscall so we need to compile getcwd as a function using this code, instead of using FreeBSD's syscall... What you are saying, is that libc must be used as a compatibility shell, right? and as Bruce will point out... the fact that -current's libc even builds on -stable and has run is completely by chance... Exactly. So are running binaries. our build of libc and tools should detect the system that we are on (or be told the type of system) and react accordingly... before this time we have been lucky that it hasn't been needed, but now we need it... Exactly. This has been discussed in another thread with Rodney. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dump device
Could you send med the output of fdisk da0 disklabel da0 please ? In message [EMAIL PROTECTED], German Tischler writes: Hi. dumpon -v /dev/da0s1b is failing here with dumpon: sysctl: kern.dumpdev: No space left on device Alright, it doesn't have minor number 1 as it is supposed to have from the manpage, but using /dev/da0b (supposed to be the same device) brings me to the same error. What am I doing wrong ? -- German Tischler[EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
3.3-stable nfsv3/udp server panic (was: Re: vm_fault: fault on nofault entry)
Hi,
we're experiencing panics on 3.3-stable as of 21st of September,
which looks alike the ones, which were happening with 3.[12] versions.
panic before (once per 1-2 day) was for SMP kernel, new one
is for kernel without SMP on the same nfs server, now after 7.5 day of work
# gdb -k kernel.37 vmcore.37
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 2756608
initial pcb at 22a0c0
panicstr: vm_fault: fault on nofault entry, addr: ce024000
panic messages:
---
panic: vm_fault: fault on nofault entry, addr: ce024000
syncing disks... 64 44 25 7 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up
(da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0
(da1:ahc1:0:1:0): Invalid command operation code
dumping to dev 20401, offset 1691306
dump 512 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 boot (howto=256) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) backtrace
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc013d485 in panic (
fmt=0xc02089e6 "vm_fault: fault on nofault entry, addr: %lx")
at ../../kern/kern_shutdown.c:446
#2 0xc01c9792 in vm_fault (map=0xc0240d2c, vaddr=3456253952,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:232
#3 0xc01ee0c8 in trap_pfault (frame=0xd2dd49dc, usermode=0, eva=3456256104)
at ../../i386/i386/trap.c:824
#4 0xc01edd7a in trap (frame={tf_es = 16, tf_ds = -1022492656,
tf_edi = 14436, tf_esi = -1022433536, tf_ebp = -757249380,
tf_isp = -757249532, tf_ebx = -838711196, tf_edx = -847782512,
tf_ecx = 8191, tf_eax = 39012, tf_trapno = 12, tf_err = 0,
tf_eip = -1071897493, tf_cs = 8, tf_eflags = 66178, tf_esp = -755096640,
tf_ss = -757248584}) at ../../i386/i386/trap.c:437
#5 0xc01c246b in ufs_lookup (ap=0xd2dd4ad8) at ../../ufs/ufs/ufs_lookup.c:238
#6 0xc01c727d in ufs_vnoperate (ap=0xd2dd4ad8)
at ../../ufs/ufs/ufs_vnops.c:2299
#7 0xc015c4a4 in vfs_cache_lookup (ap=0xd2dd4b34) at vnode_if.h:55
#8 0xc01c727d in ufs_vnoperate (ap=0xd2dd4b34)
at ../../ufs/ufs/ufs_vnops.c:2299
#9 0xc015e975 in lookup (ndp=0xd2dd4d94) at vnode_if.h:31
#10 0xc019e639 in nfs_namei (ndp=0xd2dd4d94, fhp=0xd2dd4d0c, len=2,
slp=0xc2fa6e00, nam=0xc3d1b060, mdp=0xd2dd4c48, dposp=0xd2dd4c44,
---Type return to continue, or q return to quit---
retdirp=0xd2dd4c2c, p=0xd2d7af40, kerbflag=0, pubflag=0)
at ../../nfs/nfs_subs.c:1662
#11 0xc0187277 in nfsrv_lookup (nfsd=0xc3608d00, slp=0xc2fa6e00,
procp=0xd2d7af40, mrq=0xd2dd4e34) at ../../nfs/nfs_serv.c:476
#12 0xc01a0106 in nfssvc_nfsd (nsd=0xd2dd4e94, argp=0x8071f04 "", p=0xd2d7af40)
at ../../nfs/nfs_syscalls.c:656
#13 0xc019fa21 in nfssvc
sigset_t: a summary
Ok,
While in general the integration went well, a couple of issues have been
raised. These are:
1. building with a -current source tree on -stable fails. This also
means that we currently don't have the possibility to upgrade
from -stable to -current.
2. Incompatibilities wrt to the disappearence of sigcontext and the
undocumented 4th argument to signal handlers.
3. Numerous style bugs and namespace pollution in the last commit.
I don't think I should try to solve all issues at once.
The way I see it is:
o Fixing issue 1 (cross-compilation) needs a concession. I like
to really solve the actual problem, because that would help to
support multiple architectures, including new ones. Other
solutions have been proposed, each with different pros and
cons, but they all are bandaids to different extends (IMO).
o Fixing issue 2 (incompatibilities) is more urgent. We are now
in a position to fix what was broken. The problem will get
harder to fix the longer we wait.
o Fixing issue 3 (non-critical bugs) is not urgent, but there
may be bugs that cause breakage. I suggest that urgent bugs
get fixed ASAP. Others may be fixed at any time.
So, to start with issue 2:
To start with the beginning:
1. Should the ucontext_t changes be backed out, or is this the
way we would like to go? (but only it better :-)
2. The 4th argument issue (pointed out by Alan) can be easily
fixed. See the attached patch. If this is allright with
everyone, I'll commit it (assuming Q1 is answered positive).
Corrections, additions and the likes are welcome (as usual :-)
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
Index: i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.364
diff -u -r1.364 machdep.c
--- machdep.c 1999/10/01 07:49:37 1.364
+++ machdep.c 1999/10/01 09:13:32
@@ -687,6 +687,7 @@
else {
/* Old FreeBSD-style arguments. */
sf.sf_siginfo = code;
+ sf.sf_addr = (char *)regs-tf_err;
sf.sf_ahu.sf_handler = catcher;
}
Index: include/sigframe.h
===
RCS file: /home/ncvs/src/sys/i386/include/sigframe.h,v
retrieving revision 1.1
diff -u -r1.1 sigframe.h
--- sigframe.h 1999/09/29 15:06:23 1.1
+++ sigframe.h 1999/10/01 09:11:38
@@ -68,12 +68,12 @@
struct sigframe {
/*
-* The first three members may be used by applications.
+* The first four members may be used by applications.
*/
register_t sf_signum;
register_t sf_siginfo; /* code or pointer to sf_si */
register_t sf_ucontext;/* points to sf_uc */
- register_t __spare__; /* Align sf_ahu */
+ char*sf_addr; /* undocumented 4th arg */
union {
__siginfohandler_t *sf_action;
__sighandler_t *sf_handler;
Recent kernel hangs during boot with pnp sio.
I have a pnp modem "SupraExpress 56i Sp V.90" that works fine with a kernel from Aug 22. Here is an excerpt from a successful boot: atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A --- sio2 at port 0x3e8-0x3ef irq 11 on isa0 --- sio2: type 16550A Waiting 5 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 3 lun 0 sa0: HP C1533A 9406 Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 8) changing root device to da0s3a [...] Todays GENERIC kernel hangs after correctly detecting sio2, with no keyboard input, reboot necessary, yada yada yada. Disabling sio2 from the config menu will let it boot. Here's a verbose log of todays GENERIC kernel with sio2 disabled: us: fast PIO disabled intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: d80a chip1: UHCI USB controller irq 9 at device 4.2 on pci0 chip2: Intel 82371AB Power management controller at device 4.3 on pci0 ahc0: Adaptec aic7880 Ultra SCSI adapter irq 9 at device 6.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: internal 50 cable is present, internal 68 cable is present ahc0: external cable is present ahc0: BIOS eeprom not present ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: Downloading Sequencer Program... 411 instructions downloaded fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 12 at device 10.0 on pci0 fxp0: Ethernet address 00:a0:c9:b2:18:ef bpf: fxp0 attached vga-pci0: ATI Mach64-GX graphics accelerator at device 11.0 on pci0 ahc1: Adaptec 2940 Ultra SCSI adapter irq 10 at device 12.0 on pci0 ahc1: Reading SEEPROM...done. ahc1: internal 50 cable not present, internal 68 cable not present ahc1: external cable is present ahc1: BIOS eeprom is present ahc1: High byte termination Enabled ahc1: Low byte termination Enabled ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Downloading Sequencer Program... 411 instructions downloaded fe0: not probed (disabled) fdc0: not probed (disabled) wdc0: not probed (disabled) wdc1: not probed (disabled) adv0: not probed (disabled) bt0: not probed (disabled) aha0: not probed (disabled) wt0: not probed (disabled) mcd0: not probed (disabled) matcd0: not probed (disabled) scd0: not probed (disabled) atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d psm0: current command byte:0067 kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status: psm0: failed to reset the aux device. vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa 0x2 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sc0: fb0 kbd0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at
Re: sigset_t: a summary
Marcel Moolenaar wrote: So, to start with issue 2: To start with the beginning: 1. Should the ucontext_t changes be backed out, or is this the way we would like to go? (but only it better :-) I think we want to keep the ucontext changes. SUSv2 requires them when SA_SIGINFO is set. They'll also make it easier to support efficient user thread context switches (with get/set/make/swapcontext), and also provides a hook for a kernel upcall mechanism (scheduler activations). Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mouse breakage in Current
Hi, Since CVSuping yesterday (after Marcels sig changes) my RS232 mouse has stopped working. It no longer works in XFree86 3.9.16 which talks directly to /dev/cuaa0 And I cannot get the mouse to work in /stand/sysinstall either (with moused). cat /dev/cuaa0 does give me characters when I move the mouse around. Anyone got any ideas? Roger -- Roger Hardiman| Telepresence Research Group [EMAIL PROTECTED] | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Marcel Moolenaar [EMAIL PROTECTED] writes: The problem --- When doing a make world, tools are being built that are used by the build process. This is to make sure that the tools are appropriate for doing a make world. The problem we now face is that the sigset_t change causes this to break. The tools that are being built use new syscalls not present in a kernel. Not only that, the new tools expect a different sigframe in general. So, the problem can be split into: A) New syscalls using the new sigset_t (sigaction and so on) B) A new sigframe (new siginfo, no sigcontext but ucontext_t) How about this: early in make world, we check whether or not the current kernel supports the new syscalls. If it does, good. If it doesn't, we build and load a small module which installs syscalls which translate the sigset_t stuff into something the old syscalls can grok. Does that make sense to any of you guys? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: something odd w/ bind/named, I think
Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] writes: Anyways, why are you running CURRENT on an ircd? Why not go with STABLE? There's no reason not to run -CURRENT on an IRC server, provided one is qualified to run -CURRENT in the first place. If one is not, the preferred version would be 3.3-RELEASE or newer with my TCP/IP patches (http://www.freebsd.org/~des/software/) applied. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
It seems Daniel M. Eischen wrote: More info on the kernel hang. Removing pnp from the kernel configuration will allow me to boot and successfully detects my pnp modem. So the culprit seems to be the new pnp code. Suggestions welcome. Hmm, I also have severe problems with the PnP stuff and my 3C509 cards, it just wont work as the pnp code finds and allocates adresses for the card, but the card probe doesn't pick them up... -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dump device
On Fri, Oct 01, 1999 at 09:35:32AM +0200, Poul-Henning Kamp wrote: Could you send med the output of fdisk da0 disklabel da0 please ? Greg's hint already solved the problem. I had put more memory into the machine and forgot to increase the swapspace, so it could not hold a coredump anymore. The message of dumpon should have told me, but though I was standing in a forest I still didn't see a tree. If you still want the disklabel and fdisk output, please tell me. In message [EMAIL PROTECTED], German Tischler writes: Hi. dumpon -v /dev/da0s1b is failing here with dumpon: sysctl: kern.dumpdev: No space left on device Alright, it doesn't have minor number 1 as it is supposed to have from the manpage, but using /dev/da0b (supposed to be the same device) brings me to the same error. What am I doing wrong ? -- German Tischler [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata driver (again)
A dmesg to start with would be fine that way I may be able to reproduce it here pn semilar HW. wdc0: unit 0 (wd0): ST39140A, LBA, DMA, 32-bit, multi-block-16, sleep-hack wd0: 8693MB (17803440 sectors), 1108 cyls, 255 heads, 63 S/T, 512 B/S (sleep-hack I turned on last night) /kernel: wd0: wdtimeout() DMA status 4 Thats not the ata driver thats the wd driver :) Looks like interrupt lossage to me... yes it is, it happens to me with either driver. I keep suspecting it is something other than the disk or OS , like the motherboard or something but I have no idea how to find out. Thanks Luke --- To be sure of hitting the target, shoot first and, whatever you hit, call it the target. XFMail 1.3 FreeBSD-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sigset_t: a summary
1. Should the ucontext_t changes be backed out, or is this the way we would like to go? (but only it better :-) We need something. Rather than say 'something better', I'd need to see what that better things is. However, given Bruce's comments earlier, it seems like we need to have ucontext_t to stay compatible. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ahc failure while updating from pre-signal-change
Hi, last cvsup: 1 Okt 18:19 GMT I've build a new kernel and rebooted to be able to make a new world (aktual system: pre-signal-change, around Sep 29). Right after "Automatic reboot in progress..." I get: ---snip--- (da0:ahc0:0:0:0): have seen Data Phase. Length = 0. NumSGs = 1. (da0:ahc0:0:0:0): data overrun detected in Data-In phase. Tag == 0xe. /dev/rda0s1a: CANNOT READ: BLK 16 ---snip--- and fsck aborts. The "(da0:..." parts are repeated multiple times. Booting the old kernel works and fsck says "FILESYSTEM CLEAN" (and I'm not able to upgrade to post-signal-change). This happens with sources cvsupped at 15:xx GMT (german mirror) to 18:19 GMT (directly from cvsup.freebsd.org). dmesg from the working kernel: ---snip--- FreeBSD 4.0-CURRENT #6: Wed Sep 29 16:57:27 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/WORK Timecounter "i8254" frequency 1193182 Hz CPU: Celeron (400.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA T,PSE36,MMX,FXSR real memory = 134205440 (131060K bytes) avail memory = 126263296 (123304K bytes) Preloaded elf kernel "kernel.WORK" at 0xc039d000. VESA: v2.0, 4096k memory, flags:0x1, mode table:0xc0338f22 (122) VESA: Matrox Graphics Inc. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443LX (440 LX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443LX (440 LX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 4.1 on pci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 9 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped e400 ahc0: Adaptec aic7880 Ultra SCSI adapter irq 9 at device 6.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ed0: NE2000 PCI Ethernet (RealTek 8029) irq 15 at device 10.0 on pci0 ed0: address 00:80:ad:40:bd:e7, type NE2000 (16 bit) pci0: unknown card DPZ0001 (vendor=0x121a, dev=0x0001) at 11.0 vga-pci0: Matrox MGA 1024SG/1064SG/1164SG graphics accelerator irq 11 at device 12.0 on pci0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x6 on isa0 sc0: VGA 16 virtual consoles, flags=0x206 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): Conner Peripherals 420MB - CFS420A wd0: 406MB (832608 sectors), 826 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): IOMEGA ZIP 100 ATAPI/23.D, removable, intr, iordis wfd0: medium type unknown (no disk) wfd0: buggy Zip drive, 64-block transfer limit set fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x20010 on isa0 sio0: type ST16650A sio1 at port 0x2e8-0x2ef irq 10 flags 0x2 on isa0 sio1: type ST16650A joy0 at port 0x201 on isa0 joy0: joystick pca0 at port 0x40 on isa0 pca0: PC speaker audio driver isic0 at port 0x300 irq 3 flags 0x4 on isa0 isic0: AVM A1 or AVM Fritz!Card isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x16e0) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x6e0, AddrB=0xee0) ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 pcm0: Vibra16X at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, logging limited to 100 packets/entry by default i4b: ISDN call control device attached i4bisppp: 2 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 2 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4btel: 1 ISDN telephony interface device(s) attached i4brbch: 2 raw B channel access device(s) attached i4btrc: 2 ISDN trace device(s) attached ds0 XXX: driver didn't set ifq_maxlen IP Filter: initialized. Default = pass all, Logging = enabled Waiting 5 seconds for SCSI devices to settle changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: MICROP 4743NS
Re: new sigset_t and upgrading: a proposal
Marcel Moolenaar wrote: Dag-Erling Smorgrav wrote: How about this: early in make world, we check whether or not the current kernel supports the new syscalls. If it does, good. If it doesn't, we build and load a small module which installs syscalls which translate the sigset_t stuff into something the old syscalls can grok. Does that make sense to any of you guys? That has been proposed by someone (sorry, I can't remember who exactly). We still need a consensus as to what we should do. Personally, I now like to fix this at the core of the problem: truly support cross-compilations. This implies (IMO) that the source tree is never used to build the tools with which a world is built (ideally). Such a solution may take too long to be implemented to be used as a solution now, though. But this still doesn't entirely solve the problem. You still have to build and install a new kernel before installing the world. While this is typically what most -current folks do anyways, it still prevents backing up to a previous kernel after the install world. It seems like libc should be built to be compatible with the kernel that is currently running. After installing world and testing the new kernel, a subsequent make world (or some other target to get just the libs) can be done to make the libs use the new syscalls. I like to keep old known working kernels around just in case there are some serious bugs with the current one. Once a kernel has proven itself somewhat stable, you can then upgrade the libs. This is why I kind of like (was it?) Peter Wemms libc hack. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc failure while updating from pre-signal-change
Please boot your old system and email the output from fdisk da0 disklabel da0 Poul-Henning In message [EMAIL PROTECTED], [EMAIL PROTECTED] -SB.de writes: Hi, last cvsup: 1 Okt 18:19 GMT I've build a new kernel and rebooted to be able to make a new world (aktual system: pre-signal-change, around Sep 29). Right after "Automatic reboot in progress..." I get: ---snip--- (da0:ahc0:0:0:0): have seen Data Phase. Length = 0. NumSGs = 1. (da0:ahc0:0:0:0): data overrun detected in Data-In phase. Tag == 0xe. /dev/rda0s1a: CANNOT READ: BLK 16 ---snip--- and fsck aborts. The "(da0:..." parts are repeated multiple times. Booting the old kernel works and fsck says "FILESYSTEM CLEAN" (and I'm not able to upgrade to post-signal-change). This happens with sources cvsupped at 15:xx GMT (german mirror) to 18:19 GMT (directly from cvsup.freebsd.org). dmesg from the working kernel: ---snip--- FreeBSD 4.0-CURRENT #6: Wed Sep 29 16:57:27 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/WORK Timecounter "i8254" frequency 1193182 Hz CPU: Celeron (400.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA T,PSE36,MMX,FXSR real memory = 134205440 (131060K bytes) avail memory = 126263296 (123304K bytes) Preloaded elf kernel "kernel.WORK" at 0xc039d000. VESA: v2.0, 4096k memory, flags:0x1, mode table:0xc0338f22 (122) VESA: Matrox Graphics Inc. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443LX (440 LX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443LX (440 LX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 4.1 on pci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 9 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped e400 ahc0: Adaptec aic7880 Ultra SCSI adapter irq 9 at device 6.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ed0: NE2000 PCI Ethernet (RealTek 8029) irq 15 at device 10.0 on pci0 ed0: address 00:80:ad:40:bd:e7, type NE2000 (16 bit) pci0: unknown card DPZ0001 (vendor=0x121a, dev=0x0001) at 11.0 vga-pci0: Matrox MGA 1024SG/1064SG/1164SG graphics accelerator irq 11 at device 12.0 on pci0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x6 on isa0 sc0: VGA 16 virtual consoles, flags=0x206 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): Conner Peripherals 420MB - CFS420A wd0: 406MB (832608 sectors), 826 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): IOMEGA ZIP 100 ATAPI/23.D, removable, intr, iordis wfd0: medium type unknown (no disk) wfd0: buggy Zip drive, 64-block transfer limit set fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x20010 on isa0 sio0: type ST16650A sio1 at port 0x2e8-0x2ef irq 10 flags 0x2 on isa0 sio1: type ST16650A joy0 at port 0x201 on isa0 joy0: joystick pca0 at port 0x40 on isa0 pca0: PC speaker audio driver isic0 at port 0x300 irq 3 flags 0x4 on isa0 isic0: AVM A1 or AVM Fritz!Card isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x16e0) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x6e0, AddrB=0xee0) ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 pcm0: Vibra16X at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, logging limited to 100 packets/entry by default i4b: ISDN call control device attached i4bisppp: 2 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 2 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4btel: 1 ISDN telephony interface device(s) attached i4brbch: 2 raw B channel access device(s) attached i4btrc: 2 ISDN trace device(s) attached ds0 XXX: driver didn't set ifq_maxlen IP Filter:
Re: new sigset_t and upgrading: a proposal
Daniel Eischen wrote: Marcel Moolenaar wrote: Dag-Erling Smorgrav wrote: How about this: early in make world, we check whether or not the current kernel supports the new syscalls. If it does, good. If it doesn't, we build and load a small module which installs syscalls which translate the sigset_t stuff into something the old syscalls can grok. Does that make sense to any of you guys? That has been proposed by someone (sorry, I can't remember who exactly). We still need a consensus as to what we should do. Personally, I now like to fix this at the core of the problem: truly support cross-compilations. This implies (IMO) that the source tree is never used to build the tools with which a world is built (ideally). Such a solution may take too long to be implemented to be used as a solution now, though. But this still doesn't entirely solve the problem. You still have to build and install a new kernel before installing the world. While this is typically what most -current folks do anyways, it still prevents backing up to a previous kernel after the install world. You can easily install a kernel as part of the upgrade process. A complete upgrade would be something like: 1. Verify and/or install cross-compilation tools 2. Build world 3. Build kernel 4. Copy tools that are used by the install process 5. install kernel 6. install world 7. reboot If you install a kernel before installing world, you can easily recover when the install world fails: reboot. The new kernel is capable of running those binaries that got installed before the breakage. It seems like libc should be built to be compatible with the kernel that is currently running. After installing world and testing the new kernel, a subsequent make world (or some other target to get just the libs) can be done to make the libs use the new syscalls. You still want to use the source tree to tools that run on the machine that does the building. Assume for a moment that such can't be done. What you get is real cross-compilation. This is why I kind of like (was it?) Peter Wemms libc hack. It's a solution that may work out very well, yes. But it seems to me that cross-compilation is on everybodies wishlist for as long as FreeBSD exists (well almost :-) That's why I'm pressing it. This doesn't rule out interim solutions of course. Real cross-compilation may not be worth the effort/problems, but you can't really tell if you haven't tried it... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
machine freeze at boot
In the last month something has changed that now causes my machine to lock up just before PCI bus detection (I don't know if it happens in the PCI detection or in the driver before that). It appears that it happens early enough that the kernel debugger isn't ready, yet, as the magic C-A-Esc doesn't drop me into kdb. I don't have my motherboard specifications handy, but does anybody know of why this might be occuring. thanks -jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CVSup core dumps
I updated yesterday, installed the world and a new kernel. That all worked. Today when I run cvsup with the same supfile I used yesterday I get a core dump: # cvsup /root/current-supfile *** *** runtime error: ***Segmentation violation - possible attempt to dereference NIL *** Abort trap (core dumped) # cvsup /root/current-supfile If I truss it, with truss cvsup supfile, it works. # file cvsup.core cvsup.core: data # gdb cvsup.core 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"... "/usr/ports/lang/modula-3/cvsup.core": not in executable format: File format not recognized (I'm in that directory in order to rebuild cvsup for this build to get cvsup working again, but I can't compile modula-3...). Is there a new static binary to use? I thought the problem was my hostname, which was null, but I went ahead and set that (this is on a laptop doing DHCP). TIA, ==Leonard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc failure while updating from pre-signal-change
On Fri, Oct 01, 1999 at 09:35:51PM +0200, Poul-Henning Kamp wrote: Please boot your old system and email the output from fdisk da0 disklabel da0 ---snip--- (da0:ahc0:0:0:0): have seen Data Phase. Length = 0. NumSGs = 1. (da0:ahc0:0:0:0): data overrun detected in Data-In phase. Tag == 0xe. /dev/rda0s1a: CANNOT READ: BLK 16 ---snip--- I am in exactly the same boat. wopr:~$ fdisk da0 *** Working on device /dev/rda0 *** parameters extracted from in-core disklabel are: cylinders=29310 heads=29 sectors/track=21 (609 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=29310 heads=29 sectors/track=21 (609 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 1785 (8715 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 21/ head 28 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED wopr:~$ disklabel da0 # /dev/rda0c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: sectors/unit: 1785 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: 104857604.2BSD 1024 819216 # (Cyl.0 - 65*) b: 524288 1048576 swap# (Cyl. 65*- 97*) c: 17850unused0 0 # (Cyl.0 - *) d: 5103248 127467524.2BSD 1024 819216 # (Cyl. 793*- *) e: 4194304 15728644.2BSD 1024 819216 # (Cyl. 97*- 358*) f: 4194304 57671684.2BSD 1024 819216 # (Cyl. 358*- 620*) g: 1392640 99614724.2BSD 1024 819216 # (Cyl. 620*- 706*) h: 1392640 113541124.2BSD 1024 819216 # (Cyl. 706*- 793*) -- Matthew Hunt [EMAIL PROTECTED] * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sigset_t: a summary
Nate Williams wrote:
1. Should the ucontext_t changes be backed out, or is this the
way we would like to go? (but only it better :-)
We need something. Rather than say 'something better', I'd need to see
what that better things is. However, given Bruce's comments earlier, it
seems like we need to have ucontext_t to stay compatible.
This is better:
typedef struct __ucontext_t {
/*
* Keep the order of the first two fields. Also,
* keep them the first to fields in the structure.
* This way we can have a union with struct
* sigcontext and ucontext_t. This allows us to
* support them both at the same time.
* note: the union is not defined, though.
*/
mcontext_t uc_mcontext;
sigset_tuc_sigmask;
struct __ucontext_t *uc_link;
stack_t uc_stack;
int __spare__[8];
} ucontext_t;
typedef struct __mcontext_t {
/*
* The first 3 fields are must match the definition
* of sigcontext. So that we can support sigcontext
* and ucontext at the same time.
*/
int mc_onstack; /* XXX - struct sigcontext
compat. */
int mc_gs;
struct trapframe mc_tf;
int mc_fpregs[28]; /* env87 + fpacc87 + u_long */
int __spare__[16];
} mcontext_t;
struct sigcontext {
int sc_onstack; /* sigstack state to restore */
int sc_gs;
int sc_fs;
int sc_es;
int sc_ds;
int sc_edi;
int sc_esi;
int sc_ebp;
int sc_isp;
int sc_ebx;
int sc_edx;
int sc_ecx;
int sc_eax;
int sc_trapno;
int sc_err;
int sc_eip;
int sc_cs;
int sc_efl;
int sc_esp; /* machine state */
int sc_ss;
int sc_fpregs[28]; /* XXX - mcontext_t compat. */
int sc_spare[16]; /* XXX - mcontext_t compat. */
sigset_t sc_mask; /* signal mask to restore */
};
The Alpha port has similar construct...
The third argument can now be defined as either struct sigcontext or as
ucontext_t.
Yawn -- Off to bed...
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: BEWARE: CAM changes broke AHC!
At 06:03 AM 10/02/99 +0800, Peter Wemm wrote: If you boot with a -current kernel: (da0:ahc0:0:0:0) data overrun detected in Data-In phase. Tag = 0x8 (da0:ahc0:0:0:0) Have seen Data Phase. Length = 0, NumSGs = 1 Backing out the following sys/cam/scsi change set: Something also happened on my system with a DPT controller and builtin adaptec scsi on mother board. (Intel PR440FX) The system just hangs right after mounting the swap. A kernel from yesterday works fine. The boot disk is on the DPT controller (Raid Type 1) Nothing on the adaptec but a CDROM. Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BEWARE: CAM changes broke AHC!
I am particularly suspicious about this:
@@ -284,26 +283,14 @@
return (error); /* error code from tsleep */
}
- if ((softc-flags DA_FLAG_OPEN) == 0) {
- if (cam_periph_acquire(periph) != CAM_REQ_CMP)
- return(ENXIO);
- softc-flags |= DA_FLAG_OPEN;
- }
+ if (cam_periph_acquire(periph) != CAM_REQ_CMP)
+ return(ENXIO);
+ softc-flags |= DA_FLAG_OPEN;
At first glance, it would appear it's re-inquiring on each open instead of
the first open, including while it's mounted. I wasn't sure, so rather than
risk disks, I backed the lot out and it worked again.
daopen() is now supposed to be called only if the physical device is not
already open for some subdevice. However, some old races seem to be back.
Suppose there are concurrent opens on the same device. Both will find
dsisopen() == 0 in diskopen(), since dsopen() is not called until after
daopen() completes, so both will enter daopen(), but daopen() is no longer
designed to handle concurrent opens. The first one will obtain a lock
(slightly before the above code) and the second one will sleep. The second
one will continue in daopen() after the first daopen() completes, and will
apparently do some damage. One possible source of damage is clobbering the
label while the first of the two opens is still using it. There are a lot
of i/o's which will block and allow the opens to get in each others way.
The old version unnecessarily did a full physical open for all non-first
opens, not just for racing ones, but it had no problems with the label since
the label was a local variable.
Fix: move the locking up to diskopen().
There may be similar problems for last-closes. There should be locks to
prevent opens while last-closes are in progress. Note that checks of
vcount() in vfs don't provide sufficent locking for multiplexed physical
devices like disks and and sio/cua, since concurrent last-closes are
possible for different subdevices.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Let me chime in here. We *DO* care about ancient AIC drivers as long : as no PCMCIA alternative exists. Justin has said that porting old scsi aic to cam wouldn't be too hard, but would still provide a level of buginess that is too high.. Otherwise, i'd have done that a long time ago... I don't know, I have never used the aic driver before. It would seem that aic users were not that unhappy with the driver. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : OTOH, if we are still perl-safe, I could send you the newer perl : script, so you can adapt from that. FWIW, one mus have perl installed to build a kernel. Yeah, but one must have world installed to build a kernel. Having perl as part of TOOLS is the thing that sucks. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : I don't know, I have never used the aic driver before. It would seem : that aic users were not that unhappy with the driver. I tried getting it to work on 5 different occasions on one of 8 different cards. 0 for 8. I didn't try the pcmcia attachment. It worked OK under low low, but hung the system typically under a moderate load (say fsck). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
