Re: Now that sigcontext is gone ...
P.S. This also reminds me that FreeBSD is non-standard relative to Linux and all of the major vender commercial Unices in that a disallowed access, such as a write to a read-only region of memory, generates a SIGBUS rather than a SIGSEGV. Yes, this even violates the 1996 POSIX spec. So lets make the change for 4.0. :-) Just how much code will break? -- -- David([EMAIL PROTECTED]) 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 wrote: 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. You missed the point. This is -current, right? You do all of the above, and then reboot and find out that the new kernel doesn't work. What do you do? The default procedure is to boot kernel.old. 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... From where I stand, it doesn't seem that cross-compilation will solve the problem of world needing to be built before kernel (and that includes installworld). -- 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...
On Wed, Sep 29, 1999 at 11:05:49PM +1200, Joe Abley wrote: On Wed, Sep 29, 1999 at 12:02:09PM +0200, Mark Murray wrote: There is breakage in the new FICL. This fixes it... [awk diff] I remember a long time ago someone asked me to make some modifications to softcore.awk to compress the textual ficl keywords by eliminating double-spaces and newlines, and that kind of thing. Modifications have been made; patch in kern/14087. It produces identical output to the new softcore.pl for my test case of cat sys/boot/ficl/softwords/*.fr People (more) familiar with ficl syntax might like to craft some awkward constructs and check that I'm handling them legally. Note that the script contains one gawk-ism (use of strftime() to include a cosmetic "last update" comment in the generated softcore.c). In my opinion, this should be eliminated -- it seems like a needless GNUism to me. gawk(1) says that the use of the character class [[:space:]] is consistent with POSIX 1003.2 (and I have no reason to disbelieve it). However, [[:space:]] also seems to be frequently misunderstood by other common awks, so it might also be considered a candidate for removal in the interests of portability. The alternative is a bit messier, though, and not necessarily portable across different locales. Joe 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
Ok, I've committed what I belive is a fix for the problem. It was not the locking as Bruce suggested, although his suggestion still has a point, it was si_iosize_max which was uninitialized, which confuses minphys and subsequently various other stuff. -- 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
Re: Now that sigcontext is gone ...
On Sat, 2 Oct 1999, David O'Brien wrote: P.S. This also reminds me that FreeBSD is non-standard relative to Linux and all of the major vender commercial Unices in that a disallowed access, such as a write to a read-only region of memory, generates a SIGBUS rather than a SIGSEGV. Yes, this even violates the 1996 POSIX spec. So lets make the change for 4.0. :-) Just how much code will break? All that has been changed during porting to catch the other signal? And what will we be issuing sigbus for? -- -- David([EMAIL PROTECTED]) 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: BEWARE: CAM changes broke AHC!
I, too, am having problems with the CAM code; but my SCSI drive(s) are NOT
boot drives!
Attempting ANY transfer on the drive evokes this response:
Oct 2 21:34:29 bsd300 /kernel: (da0:ncr0:0:3:0): extraneous data discarded.
Oct 2 21:34:29 bsd300 /kernel: (da0:ncr0:0:3:0): COMMAND FAILED (9 0)
@0xc0b3e600.
Oct 2 21:34:31 bsd300 /kernel: (da0:ncr0:0:3:0): extraneous data discarded.
Oct 2 21:34:31 bsd300 /kernel: (da0:ncr0:0:3:0): COMMAND FAILED (9 0)
@0xc0b3e600.
Reverting to an "older" kernel works fine; so I don't think it is hardware.
The applicable dmesg output:
Oct 2 21:32:59 bsd300 /kernel: FreeBSD 4.0-CURRENT #0: Sat Oct 2 14:29:38
EST 1999
Oct 2 21:32:59 bsd300 /kernel: ncr0: ncr 53c810a fast10 scsi irq 10 at
device 11.0 on pci0
Oct 2 21:32:59 bsd300 /kernel: da0 at ncr0 bus 0 target 3 lun 0
Oct 2 21:32:59 bsd300 /kernel: da0: CONNER CFP4207S 4.28GB 1524 Fixed
Direct Access SCSI-2 device
Oct 2 21:32:59 bsd300 /kernel: da0: 10.000MB/s transfers (10.000MHz, offset
8)
Oct 2 21:32:59 bsd300 /kernel: da0: 4096MB (8388608 512 byte sectors: 255H
63S/
T 522C)
- Original Message -
From: Poul-Henning Kamp [EMAIL PROTECTED]
To: Peter Wemm [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, October 02, 1999 4:27 PM
Subject: Re: BEWARE: CAM changes broke AHC!
In message [EMAIL PROTECTED], Peter Wemm
writes
:
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:
revision 1.39
date: 1999/10/01 09:34:09; author: phk; state: Exp; lines: +47 -117
Introduce the disk mini-layer and devstat_end_transaction_buf() in
cam/scsi.
..and the other files touched at the same time revived it and made the
system bootable again.
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.
Open is only called once on first open, so this isn't it.
--
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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
On Fri, Oct 01, 1999 at 05:57:14PM -0500, Chris Costello wrote: Try ``gdb cvsup cvsup.core'' jos:/tmp# file cvsup.core cvsup.core: lif file jos:/tmp# gdb /usr/local/bin/cvsup 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/local/bin/cvsup": not in executable format: File format not recognized "/tmp/cvsup.core" is not a core dump: File format not recognized (gdb) q The GUI version runs fine under truss tho. And the non-GUI version runs fine too, no truss'ing needed. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/bin/sh Exec format error
CVsup'ed current 2 oct 10 GMT. made and installed kernel, reboot. make world went for groceries(sp?) When i came back, screen in powersave, hit return (too many times) screen only showing "db" typed panic to reboot. Now system is hosed: it fails in rc.init (thereabout), because it claims /bin/sh: Exec format error. I can't enter single user mode either for same reason. Never mind how I recover, did I do something wrong in the above procedure? I did install new kernel before making world as the heads up says. Leif 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
At 01:19 PM 10/02/99 +0200, Poul-Henning Kamp wrote: Ok, I've committed what I belive is a fix for the problem. It was not the locking as Bruce suggested, although his suggestion still has a point, it was si_iosize_max which was uninitialized, which confuses minphys and subsequently various other stuff. My problem with locking up on startup is now gone Thanks 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: ahc failure while updating from pre-signal-change
It fixed my AHC problem with ASUS P6 MB. Thank you!! From: Poul-Henning Kamp [EMAIL PROTECTED] phk Ok, I've committed what I belive is a fix for the problem. It was not phk the locking as Bruce suggested, although his suggestion still has a point, phk it was si_iosize_max which was uninitialized, which confuses minphys phk and subsequently various other stuff. phk phk -- 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
"Daniel C. Sobral" wrote: Marcel Moolenaar wrote: 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. You missed the point. This is -current, right? You do all of the above, and then reboot and find out that the new kernel doesn't work. What do you do? The default procedure is to boot kernel.old. Read my lips: *NEVER* do a 'make world' until you've got a new bootable kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make world' because a new kernel doesn't workd is a major drama. Just Don't Do It, at least not on -current where a kernel isn't expected to work every time. You can run a -current userland *months* behind your kernel, as long as you take care of libkvm and friends. Our kernel development process is done with backwards compatability in mind, not forward compatability. You can't expect last week's kernel to know about the new syscalls that are used after you committed to a buildworld. You can expect an old world to work though. Many people I talk with regularly go *months* between building world but on the other hand build a kernel every few days or so (including me). Don't use modules if you are doing this though, or keep a /modules and / modules.old to go with the kernel. (ie: when you do a 'make install' of the kernel, move /modules to /modules.old, mkdir /modules and then build/ install fresh kld's. Modules are only really useful in -current under certain curcumstances. Mostly this is 1) if you are developing a subsystem (eg: vinum) and need a rapid turnaround without a reboot, and 2) if you are running a fairly stable build, ie: not doing recompiles for months at a time. Especially don't use a vinum module (for example) if you're doing near daily kernel builds, use the static compilation option instead. Cheers, -Peter 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
[CC: trimmed to -current] 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. ... 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. Read my lips: *NEVER* do a 'make world' until you've got a new bootable kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make world' because a new kernel doesn't workd is a major drama. These folks are 100% correct, some place some where we made a mistake and are telling users to do things in the wrong order. It might have even been myself that caused this, I just can't recall when and who said to build the world before building the kernel. But now looking at it in hindsight, this is plainly the wrong sequence, and we should correct that error as soon as possible. When did we go wrong and start saying that users should build the world before building a new kernel?If it was ``I'' that said it, I full retract any such statement, I was WRONG!. It may have been said in the patchkit days, or very early FreeBSD 1.x. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] 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
On Sat, 2 Oct 1999, Rodney W. Grimes wrote: Read my lips: *NEVER* do a 'make world' until you've got a new bootable kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make world' because a new kernel doesn't workd is a major drama. These folks are 100% correct, some place some where we made a mistake and are telling users to do things in the wrong order. It might have even been myself that caused this, I just can't recall when and who said to build the world before building the kernel. But now looking at it in hindsight, this is plainly the wrong sequence, and we should correct that error as soon as possible. What happens if we version-bump the kernel conf files so a new version of config is required? You'd have to hand-build and install config first. Or is this what we want? Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org 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
On Sat, Oct 02, 1999 at 09:45:30AM -0700, Rodney W. Grimes wrote: Read my lips: *NEVER* do a 'make world' until you've got a new bootable kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make world' because a new kernel doesn't workd is a major drama. These folks are 100% correct, some place some where we made a mistake and are telling users to do things in the wrong order. It might have even been myself that caused this, I just can't recall when and who said to build the world before building the kernel. But now looking at it in hindsight, this is plainly the wrong sequence, and we should correct that error as soon as possible. When did we go wrong and start saying that users should build the world before building a new kernel?If it was ``I'' that said it, I full retract any such statement, I was WRONG!. It may have been said in the patchkit days, or very early FreeBSD 1.x. Unless I'm mistaken, the FreeBSD Tutorial "Upgrading FreeBSD from source" tells you to "make world" before you make and install the kernel. I take it the tutorial is wrong? :) -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: free vnode isn't
sft updates? is it possible the filesystem got totally full? (that combination prooduces a bug that kirk is looking at...) julian On Sat, 2 Oct 1999, Bob Bishop wrote: Hi, panic: free vnode isn't with yesterday's kernel (cvsup Fri Oct 1 04:02:32 BST 1999), on an SMP system early on in buildworld. Skeletal traceback (must get serial console fixed up): panic getnewvnode ffs_vget ufs_lookup ufs_vnoperate vfs_cache_lookup ufs_vnoperate lookup namei unlink syscall dmesg etc available on request. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK 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: new sigset_t and upgrading: a proposal
When did we go wrong and start saying that users should build the world before building a new kernel?If it was ``I'' that said it, I full retract any such statement, I was WRONG!. It may have been said in the patchkit days, or very early FreeBSD 1.x. It's been "common culture" ever since I can remember (at least three years). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: free vnode isn't
At 10:58 am -0700 2/10/99, Julian Elischer wrote: sft updates? Yes is it possible the filesystem got totally full? (that combination prooduces a bug that kirk is looking at...) No, There's about 700M free on /usr/obj, and it was in the early tree-cleaning phase anyway. I forgot to mention that /usr/src is NFS (but it doesn't seem likely that's relevant). julian On Sat, 2 Oct 1999, Bob Bishop wrote: Hi, panic: free vnode isn't with yesterday's kernel (cvsup Fri Oct 1 04:02:32 BST 1999), on an SMP system early on in buildworld. Skeletal traceback (must get serial console fixed up): panic getnewvnode ffs_vget ufs_lookup ufs_vnoperate vfs_cache_lookup ufs_vnoperate lookup namei unlink syscall dmesg etc available on request. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh Exec format error
On Sat, Oct 02, 1999 at 02:05:37PM +0200, Leif Neland wrote: Now system is hosed: it fails in rc.init (thereabout), because it claims /bin/sh: Exec format error. I can't enter single user mode either for same reason. What about using /bin/csh for single user mode? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[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.
Doug Rabson wrote: Here, it might be the opposite. The normal sio probes pick up the pnp modem just fine, and then perhaps pnp comes along and trounces on what has already been setup/configured. Could you try this patch for me. It attempts to disable pnp devices before running the regular probes. This allows it to 'hide' those devices from the heuristic probes so that they don't get seen twice when the pnp probe happens. [ Patch elided ] This stops the kernel from hanging. The serial device (sio2) doesn't get detected during the regular probes and the pnp probe detects it. But the pnp probe detects it at the wrong IRQ (5 instead of 11). Here's an excerpt of a verbose boot: sio0: irq maps: 0x801 0x811 0x801 0x801 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x801 0x809 0x801 0x801 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: configured irq 11 not in bitmap of probed irqs 0 sio2: irq maps: 0x801 0x801 0x801 0x801 sio2: probe failed test(s): 0 1 2 4 6 7 9 ppc: parallel port found at 0x378 ppc0: ECP SPP ECP+EPP SPP 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 plip: irq 7 plip0: PLIP network interface on ppbus 0 bpf: lp0 attached lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 unknown0: SupraExpress 56i Sp V.90 at port 0x3e8-0x3ef irq 5 on isa0 What's the unknown0? Shouldn't that be sio2? Do we need the logical device ID? From pnpinfo -v: Card assigned CSN #1 Vendor ID SUP2480 (0x8024b04e), Serial Number 0x1334 PnP Version 1.0, Vendor Version 0 Device Description: SupraExpress 56i Sp V.90 Logical Device ID: SUP2480 0x8024b04e #0 Device supports I/O Range Check Compatible Device ID: SUP2080 (8020b04e) [ See my original Email for a full listing. ] CSN SUP2480 (0x8024b04e), Serial Number 0x1334 Logical device #0 IO: 0x03e8 0x 0x 0x 0x 0x 0x 0x IRQ 11 0 DMA 4 0 IO range check 0x00 activate 0x01 Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh Exec format error
:On Sat, Oct 02, 1999 at 02:05:37PM +0200, Leif Neland wrote: : Now system is hosed: it fails in rc.init (thereabout), because it claims /bin/sh: :Exec format error. : I can't enter single user mode either for same reason. : :What about using /bin/csh for single user mode? : :-- :B.Walter COSMO-Project http://www.cosmo-project.de :[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] Also, when all else fails try booting from a FreeBSD CD. Altneratively it may be possible to boot the normal kernel and use a FreeBSD CD as root by typing 'boot /kernel -C' (or -c, I forget which). -Matt Matthew Dillon [EMAIL PROTECTED] 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
On 2 October 1999 at 9:45, "Rodney W. Grimes" [EMAIL PROTECTED] wrote: When did we go wrong and start saying that users should build the world before building a new kernel?If it was ``I'' that said it, I full retract any such statement, I was WRONG!. It may have been said in the patchkit days, or very early FreeBSD 1.x. We build world first, because we need an up-to-date toolchain and config to build the kernel. Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Just how much code will break? Boehm-gc, maybe. Modula-3, maybe. I can't remember whether it catches both signals or just SIGBUS. I believe electric-fence would change as well. - Dave R. - 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.
Matthew N. Dodd wrote:
On Sat, 2 Oct 1999, Daniel M. Eischen wrote:
What's the unknown0? Shouldn't that be sio2? Do we need the logical
device ID?
Yes. Try adding 0x8024b04e to sio.c
OK, I originally did that to no avail, but I didn't make the change to
the correct file (sys/isa/sio.c, not sys/dev/sio/sio.c)! So with the
following change:
Index: sio.c
===
RCS file: /opt/b/CVS/src/sys/isa/sio.c,v
retrieving revision 1.268
diff -u -r1.268 sio.c
--- sio.c 1999/09/25 18:24:21 1.268
+++ sio.c 1999/10/02 21:54:33
@@ -568,6 +568,7 @@
{0x1005d041, "Generic IRDA-compatible device"}, /* PNP0510 */
{0x1105d041, "Generic IRDA-compatible device"}, /* PNP0511 */
{0x31307256, "USR3031"},/* USR3031 */
+ {0x8024b04e, "SupraExpress 56i Sp V.90"},
{0}
};
the modem is detected as:
sio-1: irq maps: 0x801 0x821 0x801 0x801
sio3: SupraExpress 56i Sp V.90 at port 0x3e8-0x3ef irq 5 on isa0
sio3: type 16550A
My BIOS places the modem at IRQ 11, but FreeBSD puts it at
IRQ 5. It's working fine at IRQ 5 so I am once again a happy
camper :-)
Dan Eischen
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh Exec format error
On Sat, 2 Oct 1999, Matthew Dillon wrote: Also, when all else fails try booting from a FreeBSD CD. Altneratively it may be possible to boot the normal kernel and use a FreeBSD CD as root by typing 'boot /kernel -C' (or -c, I forget which). It's -C Note however that -C is presently broken in 3.x - needs the changes at revision 1.19 of /sys/boot/i386/libi386/bootinfo.c merged from -current to make it work again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
broken SMPs, etc...
I have a very wierd case of a Dual PPRo SuperMicro board (two PCI busses) and when running -stable, I/O through boards on the second PCI bus is *really* delayed. Any notion on this? -verbose boot stuff below... -matt Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #1: Sat Oct 2 05:28:15 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/NOWORP Calibrating clock(s) ... TSC clock: 199459743 Hz, i8254 clock: 1193349 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 CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 352321536 (344064K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00346000 - 0x14ff5fff, 348848128 bytes (85168 pages) avail memory = 339275776 (331324K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Found BIOS32 Service Directory header at 0xc00fdb70 Entry = 0xfdb80 (0xc00fdb80) Rev = 0 Len = 1 PCI BIOS entry at 0xdba1 Other BIOS signatures found: ACPI: $PnP: 000f5b50 Preloaded elf kernel "kernel" at 0xc032a000. Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12378086) Probing for devices on PCI bus 0: found- vendor=0x8086, dev=0x1237, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 chip0: Intel 82440FX (Natoma) PCI and memory controller rev 0x02 on pci0.0.0 found- vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip1: Intel 82371SB PCI to ISA bridge rev 0x01 on pci0.7.0 I/O Recovery Timing: 8-bit 1 clocks, 16-bit 1 clocks Extended BIOS: disabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: enabled Interrupt Routing: A: IRQ11, B: disabled, C: IRQ9, D: IRQ10 MB0: IRQ15, MB1: found- vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base ffa0, size 4 ide_pci0: Intel PIIX3 Bus-master IDE controller rev 0x00 on pci0.7.1 intel_piix_status: primary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: primary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: primary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: ffa2 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: 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: ffaa Freeing (NOT implemented) redirected PCI irq 11. found- vendor=0x5333, dev=0x8811, revid=0x54 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=16 map[0]: type 1, range 32, base 8000, size 26 vga0: S3 Trio graphics accelerator rev 0x54 int a irq 16 on pci0.16.0 Freeing (NOT implemented) redirected PCI irq 9. found- vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=18 map[0]: type 3, range 32, base ffafe000, size 12 map[1]: type 4, range 32, base ef80, size 5 map[2]: type 1, range 32, base feb0, size 20 fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x02 int a irq 18 on pci0.19.0 fxp0: Ethernet address 00:a0:c9:aa:16:d6 bpf: fxp0 attached found- vendor=0x8086, dev=0x0960, revid=0x01 class=06-04-00,
New CVSup mirror sites
We've added quite a few new CVSup mirror sites this year. I thought it might be a good idea to list them, in the hope that some of you would help spread the load by switching to them for your CVSup updates. One common misconception is that cvsup(N+1).FreeBSD.org is somehow less up-to-date than or not as good as cvsup(N).FreeBSD.org. That's not the case at all -- the numbers mean nothing. For example, all 7 of the US mirror sites get their updates hourly from the same master site. (So do most of the non-US mirrors.) The only reasons to choose one over another are (1) to get a good network route to the mirror, and (2) to get a lightly-loaded mirror. In the US, cvsup[1-3] are very busy; clients get turned away from them on a regular basis because they are already at their limit. The other 4 mirrors are practically idle in comparison. These are all screaming fast, well-connected, well-maintained mirrors. Give them a try if you haven't already! As far as I can reconstruct from the revision history of the FreeBSD Handbook, these are the mirrors that have been added since the beginning of 1999: Brazil cvsup2.br.FreeBSD.org cvsup3.br.FreeBSD.org China cvsup.cn.FreeBSD.org Czech Republic cvsup.cz.FreeBSD.org Finland cvsup2.fi.FreeBSD.org France cvsup.fr.FreeBSD.org Korea cvsup.kr.FreeBSD.org Netherlands cvsup2.nl.FreeBSD.org Russia cvsup2.ru.FreeBSD.org Spain cvsup.es.FreeBSD.org Taiwan cvsup2.tw.FreeBSD.org cvsup3.tw.FreeBSD.org United Kingdom cvsup2.uk.FreeBSD.org USA cvsup4.FreeBSD.org cvsup6.FreeBSD.org cvsup7.FreeBSD.org --- John Polstra CVSup Mirrormeister PS - Please don't start that "Why don't we use round-robin DNS?" discussion again. There are technical reasons why it isn't feasible currently. Maybe someday. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
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. It worked for the people that it worked for. But having played with various cards and combinations, I can say that its reputation as being a fragile, bug-ridden driver was very well earned. -- \\ 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: new sigset_t and upgrading: a proposal
"Daniel C. Sobral" wrote: "Rodney W. Grimes" wrote: These folks are 100% correct, some place some where we made a mistake and are telling users to do things in the wrong order. It might have even been myself that caused this, I just can't recall when and who said to build the world before building the kernel. But now looking at it in hindsight, this is plainly the wrong sequence, and we should correct that error as soon as possible. When did we go wrong and start saying that users should build the world before building a new kernel?If it was ``I'' that said it, I full retract any such statement, I was WRONG!. It may have been said in the patchkit days, or very early FreeBSD 1.x. It might have something to do with kernel's dependency on the tools installed by world, such as gas, gcc and config. In the case of gcc/gas/ld etc we should be able to work around that. If the inline asm statements break on older gcc, then we should ifdef them to work the way they used to before egcs required they be changed. For things like config etc, that particular problem is almost over. It does very VERY little now and I can't see that we'll have incompatable changes (apart from shooting it and using a lightweight kernel/module build organizer/manager/whatever). All config(8) does at present is three things: 1: build the Makefile and options files 2: extract fragments of the static configuration and export it in MI format for the bootstrap. 3: get in the way. Thinks like libkvm, w, ps, top etc are usually best left till after a 'trial by fire' of the new kernel IMHO. Maybe a 'make afterkernel' or something to rebuild "the usual culprits" to automate that so it doesn't require a complete world as often. Just some thoughts that might make things easier... Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
