On Sat, Aug 09, 2008 at 11:56:23AM -0300, Carlos A. M. dos Santos wrote:
> 1. Try to insert the CD and wait until it stops pinning before
> starting mplayer. Some drives are a bit lazy on media recognition.
>
> 2. Run "truss mplayer ..." and look for error messages.
>
> 3. Attempt to use a diffe
On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote:
> In addition to my earlier message, it would probably be good to narrow down
> what breaks the loader for you. For example, does it work ok over serial and
> only break on vidconsole? Also, if you just backout sys/boot/i386/btx to
On Sat, Aug 09, 2008 at 03:57:21PM -0400, John Baldwin wrote:
> As you are getting BTX faults that is likely a separate issue. You will need
> to get a copy of the BTX fault message somehow.
I've got a message from BTX only once and cannot reproduce it.
However, I get loader hangs almost always
I downloaded the drivers for the chipset my belkin wireless card has, used
ndisgen to create the kernel module, which all went aok .. however when
trying to load the module it hard hangs the machine to the point of it
restarting itself .. is there something i perhaps mybe missing or am i out in
On Sat, 9 Aug 2008, Larry Rosenman wrote:
I have a current RELENG_7 running on:
http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm
with the -3+ IPMI card.
I can interact with the BIOS, etc, but no joy once we get past the loader.
Anyone have ideas?
Attached is the kernel co
Robert, reviews of sorecv_drgram:
/* XXXRW: sbwait() may not be as happy without sblock(). */
error = sbwait(&so->so_rcv);
Does not need XXX, sbwait waits for data, it's not really related
to sblock(). remove comment.
The variable orig_resid can be removed, I thin
I have a current RELENG_7 running on:
http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm
with the -3+ IPMI card.
I can interact with the BIOS, etc, but no joy once we get past the loader.
Anyone have ideas?
Attached is the kernel config, and the /var/run/dmesg.boot file.
-
On Saturday 09 August 2008 05:22:01 am Eugene Grosbein wrote:
> On Fri, Aug 08, 2008 at 12:49:28PM -0400, John Baldwin wrote:
> > My realization this morning is that software interrupts ('int X') in real
> > mode disable interrupts just like hardware interrupts do. Thus, my patch
> > changes BTX t
On Saturday 09 August 2008 09:02:12 am Eugene Grosbein wrote:
> On Sat, Aug 09, 2008 at 01:56:42PM +0200, Ulrich Spoerlein wrote:
> > > > The updated patch (same URL, new patch) is at
> > > > http://www.FreeBSD.org/~jhb/patches/btx_hang.patch
> > >
> > > Sigh, it does not fix my problem described h
On Sat, Aug 09, 2008 at 05:23:32PM +0400, KES wrote:
> 09.08.08, 16:22, "Matthew Seaman" <[EMAIL PROTECTED]>:
> > Andrew Snow wrote:
> > > Usually if there is more than IP in a given subnet on an interface, you
> > > give it a /32 netmask. Only the first IP in a subnet should have the
> > > full
On Sat, Aug 9, 2008 at 11:03 AM, Harald Weis <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 08, 2008 at 09:17:40PM -0300, Carlos A. M. dos Santos wrote:
>> On Fri, Aug 8, 2008 at 5:13 AM, Harald Weis <[EMAIL PROTECTED]> wrote:
>
>> > acd0: DVDR at ata0-master UDMA33
>> > acd0: FAILURE - INQUIRY ILLEGAL
On Fri, Aug 08, 2008 at 09:17:40PM -0300, Carlos A. M. dos Santos wrote:
> On Fri, Aug 8, 2008 at 5:13 AM, Harald Weis <[EMAIL PROTECTED]> wrote:
> > acd0: DVDR at ata0-master UDMA33
> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x2
09.08.08, 16:22, "Matthew Seaman" <[EMAIL PROTECTED]>:
> Andrew Snow wrote:
> >
> > Usually if there is more than IP in a given subnet on an interface, you
> > give it a /32 netmask. Only the first IP in a subnet should have the
> > full netmask.
> >
> > So your example should look like this
On Sat, Aug 09, 2008 at 01:56:42PM +0200, Ulrich Spoerlein wrote:
> > > The updated patch (same URL, new patch) is at
> > > http://www.FreeBSD.org/~jhb/patches/btx_hang.patch
> >
> > Sigh, it does not fix my problem described here:
> >
> > http://groups.google.ru/group/muc.lists.freebsd.stable/
Andrew Snow wrote:
Usually if there is more than IP in a given subnet on an interface, you
give it a /32 netmask. Only the first IP in a subnet should have the
full netmask.
So your example should look like this:
inet 10.11.16.14 netmask 0xff00 broadcast 10.11.16.255
inet 10.1
On Sat, 09.08.2008 at 17:22:01 +0800, Eugene Grosbein wrote:
> On Fri, Aug 08, 2008 at 12:49:28PM -0400, John Baldwin wrote:
>
> > My realization this morning is that software interrupts ('int X') in real
> > mode
> > disable interrupts just like hardware interrupts do. Thus, my patch
> > chan
Hi John,
I now figured out the "who", the "why" still eludes me.
So, after your MFC of ichss.c on June 27th the device now attaches at my
laptop. It didn't before, so it could cause no trouble.
With ichss loaded, the kernel will panic 1-3 minutes after powerd has
been started (if I kill powerd e
Usually if there is more than IP in a given subnet on an interface, you
give it a /32 netmask. Only the first IP in a subnet should have the
full netmask.
So your example should look like this:
inet 10.11.16.14 netmask 0xff00 broadcast 10.11.16.255
inet 10.11.16.9 netmask 0xfff
On Fri, 8 Aug 2008, Oliver Fromme wrote:
Andrew Thompson wrote:
> Pete French wrote:
> > > The bce driver is not properly generating link state events.
> >
> > OK, that explains why it doesnt failover - but why does looking at it
> > with ifconfig make a difference ? surely that should be 'rea
# uname -a
FreeBSD gorodok.kes.net.ua 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #0: Sun Aug 3
13:18:21 EEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KES_KERN_v7 i386
# netstat -nr
Routing tables
Internet:
DestinationGatewayFlags
On Fri, Aug 08, 2008 at 01:47:18PM -0400, Nathanael J wrote:
> Hello,
>
> I've been having spurrious crash troubles with this box a while now
> and I haven't been able to figure out why. I've ran a couple memtest
> passes on it and it didn't pick up anything. Here's a backtrace I've
> been able to
On Fri, Aug 08, 2008 at 12:49:28PM -0400, John Baldwin wrote:
> My realization this morning is that software interrupts ('int X') in real
> mode
> disable interrupts just like hardware interrupts do. Thus, my patch changes
> BTX to disable interrupts for both cases 1) and 2) now. I think this
22 matches
Mail list logo
