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
>dat
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 pcmc
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
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 le
> 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
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
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
While I don't dispute that the change rolling/rollout fixed what you see,
I'd have to say that if they're related there are *far* more serious
problems in there.
> (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
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-I
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 tra
On Fri, Oct 01, 1999, Leonard Sitongia wrote:
> # 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 "sho
Leonard Sitongia wrote:
>
> Is there a new static binary to use?
>
No. Using an old one should fix this.
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
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
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: +4
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 sysc
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:
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_
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):
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 sysca
unsubscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hi,
I found the cause of my mouse failing to work after my
recent make world.
I forgot I had just installed mgetty before my make world
and set mgett to listen to the same COM port as my mouse.
Oops.
Sorry for the noise to -current.
Roger
--
Roger Hardiman| Telepresence Research Gro
> 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 uconte
> 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): , 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
Hi!
I´m running an FTP server on my FreeBSD 4.0-CURRENT
system using BeroFTPD. If I allow many users to connect
simultaneously, after some hours I get error messages
like "ping: socket buffer overflow" or "no sockets available".
Anything requiring sockets cannot be used then. Netscape
tells me th
Soren Schmidt wrote:
> 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 a
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
Hi,
I wrote:
>With today's kernel (cvsup at Thu Sep 30 04:04:55 BST 1999), this system
>freezes (no DDB, nothing) as soon as any load is put on it (eg very early
>in buildworld).
FWIW, something that changed in the subsequent 24hrs fixed this. I'm
suspicious of the fact that the netcard:
ed1:
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 s
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.
Here's a successful verbose boot with a kernel from Sept 30th
sources.
intpm0: at devi
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-REL
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
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 t
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 se
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: at port 0x60-0x6f on isa0
atkbd0: irq 1 on atkbdc0
vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0
sc0: on isa0
sc0:
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 disapp
John-Mark Gurney wrote:
>
> hmmm.. that might be an option of providing a kld that emulates the new
> syscalls on an older kernel... I would want the patch to be available
> for staticly linking into the kernel though.. I don't like LKM/KLD's on
> servers that are suppose to be rock solid... (a
On Thu, 30 Sep 1999 17:00:28 GMT, Bob Bishop wrote:
> With today's kernel (cvsup at Thu Sep 30 04:04:55 BST 1999), this system
> freezes (no DDB, nothing) as soon as any load is put on it (eg very early
> in buildworld).
>From the discussions I see which followed the recent changes to our
sign
37 matches
Mail list logo
