[head tinderbox] failure on ia64/ia64
TB --- 2011-10-24 06:40:27 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 06:40:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-10-24 06:40:27 - cleaning the object tree TB --- 2011-10-24 06:40:32 - cvsupping the source tree TB --- 2011-10-24 06:40:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-10-24 06:40:46 - building world TB --- 2011-10-24 06:40:46 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 06:40:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 06:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 06:40:46 - SRCCONF=/dev/null TB --- 2011-10-24 06:40:46 - TARGET=ia64 TB --- 2011-10-24 06:40:46 - TARGET_ARCH=ia64 TB --- 2011-10-24 06:40:46 - TZ=UTC TB --- 2011-10-24 06:40:46 - __MAKE_CONF=/dev/null TB --- 2011-10-24 06:40:46 - cd /src TB --- 2011-10-24 06:40:46 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 06:40:47 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/
Re: sys/conf/newvers.sh vs. subversion-1.7
On Saturday, October 22, 2011 12:31:25 pm Luchesar V. ILIEV wrote:
> Speaking of that, and in the context of the recursion that svnversion
> does, something else comes to my mind...
>
> svnversion is currently executed in ${SRCDIR}/sys, so the revision
> number is relevant only to the kernel sources. But FreeBSD is not just a
> kernel, unlike Linux, so wouldn't it make more sense to actually check
> the revision directly at ${SRCDIR}, thus catching possible different
> revisions in other parts of the base system source tree?
Please no. That makes svnversion take a _lot_ longer. We used to do that,
but changed it. Also, the kernel build does not use any sources outside
of sys/, so for the kernel an svnversion of sys/ is perfectly reasonable.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC1 panic in tcp_input: negative winow.
On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote:
> On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote:
> > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote:
> > > My suggestion would be that if we won't be able to fix it before 9.0,
> > > we should turn this assertion off, as the system seems to be able to
> > > recover.
> >
> > Shipped kernels have all assertions turned off.
>
> Yes, I'm aware of that, but many people compile their production kernels
> with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg.
> corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing
> it into a printf, so it will be visible.
No, the kernel is corrupting things in other places when this is true, so
if you are running with INVARIANTS, we want to know about it. Specifically,
in several places in TCP we assume that rcv_adv >= rcv_nxt, and depend on
being able to do 'rcv_adv - rcv_nxt'.
In this case, it looks like the difference is consistently less than one
frame. I suspect the other end of the connection is sending just beyond the
end of the advertised window (it probably assumes it is better to send a full
frame if it has that much pending data even though part of it is beyond the
window edge vs sending a truncated packet that just fills the window) and that
that frame is accepted ok in the header prediction case and it's ACK is
delayed, but the next packet to arrive then trips over this assumption.
Since 'win' is guaranteed to be non-negative and we explicitly cast
'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking
for:
tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt));
I think we already handle this case ok and perhaps the assertion can just be
removed? Not sure if others feel that it warrants a comment to note that this
is the case being handled.
Also, I'm not sure if this case can "leak" into the timewait code? If so, we
will need to fix this case:
/*
* Recover last window size sent.
*/
KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt),
("tcp_twstart negative window: tp %p rcv_nxt %u rcv_adv %u", tp,
tp->rcv_nxt, tp->rcv_adv));
tw->last_win = (tp->rcv_adv - tp->rcv_nxt) >> tp->rcv_scale;
So that it sets last_win to 0 instead of some really huge value.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
On Friday, October 21, 2011 5:37:16 pm Andriy Gapon wrote: > on 22/10/2011 00:27 Andriy Gapon said the following: > > on 21/10/2011 23:33 John Baldwin said the following: > >> On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: > >>> On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: > I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i > >> mirror) > as test. [...] > It was fresh install and I choose guided partitioning (GPT) > But after reboot my server don't boot from hd. > >>> > >>> We have the same issue on a DL580 G7. Install runs fine, but when it's > >>> time for the first boot, the bootcode emits a single '-' (where usually > >>> it would be "spinning" for a moment while loading), hangs for about two > >>> seconds, and then reboots. > >> > >> Working offline with Dennis, we found that changing the CFLAGS in > >> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially > >> reverting > >> an earlier commit) fixed gptboot. The next test for someone to do would > >> be to > >> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it. > > > > Hmm, this is quite unexpected... Do you have a hypothesis why not using > > -mrtd > > could cause a problem (a miscompilation?) ? > > I've just got one: maybe the trouble is caused by the sio_putc procedure in > sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code > where 'ret ' instruction is explicitly used. > > A litmus question: do those experiencing the trouble all have BTX_SERIAL > defined? No, they all have an HP machine. > P.S. BTW, is BTX_SERIAL documented anywhere? It is not, and I strongly doubt anyone has it enabled. You can't use it with boot2 for example due to size bloat. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipmi(4)/isa woes
On Friday, October 21, 2011 5:31:01 pm Arnaud Lacombe wrote: > Hi, > > On Fri, Oct 21, 2011 at 4:19 PM, John Baldwin wrote: > > On Tuesday, October 11, 2011 6:53:11 pm Arnaud Lacombe wrote: > >> Hi, > >> > >> On Tue, Oct 11, 2011 at 6:34 PM, Arnaud Lacombe wrote: > >> > Hi folks, > >> > > >> > I've got a machine where ipmi(4) seem to be unable to fully attach. > >> > 10-current kernel complains the following way: > >> > > >> > ipmi0: at iomem 0-0x1 on isa0 > >> > ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa > >> > ipmi0: couldn't configure I/O resource > >> > device_attach: ipmi0 attach returned 6 > > > > Resource 0 is not right and will not work. In this case your BIOS has a > > buggy > > SMBIOS / DMI table entry for IPMI. > > > >> Actually, I can bypass this issue by enabling acpi(4): > >> > >> ipmi0: port 0xca2,0xca3 on acpi0 > >> ipmi0: KCS mode found at io 0xca2 on acpi > >> ipmi1: on isa0 > >> device_attach: ipmi1 attach returned 16 > >> pmtimer0 on isa0 > >> ipmi1: on isa0 > >> device_attach: ipmi1 attach returned 16 > > > > You can ignore the ipmi1 messages. > > > >> However, the driver fails right after with: > >> > >> ipmi0: Timed out waiting for GET_DEVICE_ID > > > > Are you sure you have working IPMI? The timeouts and the busted DMI table > > is consistent with a machine where IPMI is available via an optional > > daughterboard, but the daughterboard isn't installed. > > > Well, I'm not sure exactly what's the hardware layout looks like[0], > but when ipmi0 is "attached" on isa0, I can access the IPMI > controller, get the various information, set/reset the watchdog. > ipmitool(1) works like a charm. However, at some point, the KCS is > unable to reach the IPMI controller. Typical error is: > > ipmi0: KCS: Reply address mismatch > ipmi0: KCS error: 01 > ipmi0: KCS: Reply address mismatch > ipmi0: KCS error: 01 > ipmi0: Failed to set watchdog > > over an undetermined period of time. Sometimes it stops before the > watchdog triggers, sometimes it [falsely] triggers the watchdog. Ok. I've seen this sometimes where the BMC appears to lockup. The driver follows the protocol defined in the spec for resetting the KCS connection when it detects an error and will retry 3 times before it fails. There's not really much we can do once the hardware locks up however. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
> on 23/10/2011 18:27 Dennis Koegel said the following:
> > On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
> >> Working offline with Dennis, we found that changing the CFLAGS in
> >> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially
> >> reverting
> >> an earlier commit) fixed gptboot. The next test for someone to do would
> >> be to
> >> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it.
> >
> > More test results:
> >
> > gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
> > -fno-unit-at-a-time \
> > -mno-align-long-strings -mrtd [from before r225530]: Boots OK
> > gcc -Os -mrtd: Boots OK
> > gcc -O1 -mrtd: Fails
> > gcc -O1: Fails
> > gcc -O0: Fails
> > gcc -Os: Boots OK
> >
> > clang -O1: Fails
> > clang -Os: Fails
> > clang -Oz: Fails
> >
> > I've put some printf()s into gpt{,boot}.c to trace where the reboot is
> > triggered. It appears to be in drvsize() (called from gptread()). OTOH
> > the debug output may have changed where the problem occurs, I don't
> > know about that.
> >
> > With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
> > out what happens. But as for why gcc's magic -Os is required and clang's
> > output doesn't work at all, I'm clueless.
>
> Thank you for your very valuable analysis!
> I looked at a difference in assembly code of the drvsize function produced by
> gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
> places the params array and the sectors variable in a different order for
> different options. One idea is that if BIOS actually writes beyond the end of
> the array, then in one case it could be harmless (overwrites the sector
> variable), but in the other case it could be more harmful.
> I found a document that suggests a possibility of BIOS writing more bytes to
> the
> array than its current size of 0x42:
> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
>
> Of course, the size of the array is passed to BIOS at the start of the array
> and
> so a _non-buggy_ BIOS should not write beyond the array, but we live in a
> non-perfect world.
Hmm, I think we've had to do a similar workaround in the past for a different
BIOS call (SMAP maybe?). However, I do have one request, can we declare an
actual structure instead of a silly char array? Then we can remove the weird
casts with offsets into it, etc. Having an actual struct would be far more
readable and less bug-prone.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
on 24/10/2011 16:41 John Baldwin said the following:
> On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
>> on 23/10/2011 18:27 Dennis Koegel said the following:
>>> On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
Working offline with Dennis, we found that changing the CFLAGS in
sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially
reverting
an earlier commit) fixed gptboot. The next test for someone to do would
be to
try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it.
>>>
>>> More test results:
>>>
>>> gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
>>> -fno-unit-at-a-time \
>>> -mno-align-long-strings -mrtd [from before r225530]: Boots OK
>>> gcc -Os -mrtd: Boots OK
>>> gcc -O1 -mrtd: Fails
>>> gcc -O1: Fails
>>> gcc -O0: Fails
>>> gcc -Os: Boots OK
>>>
>>> clang -O1: Fails
>>> clang -Os: Fails
>>> clang -Oz: Fails
>>>
>>> I've put some printf()s into gpt{,boot}.c to trace where the reboot is
>>> triggered. It appears to be in drvsize() (called from gptread()). OTOH
>>> the debug output may have changed where the problem occurs, I don't
>>> know about that.
>>>
>>> With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
>>> out what happens. But as for why gcc's magic -Os is required and clang's
>>> output doesn't work at all, I'm clueless.
>>
>> Thank you for your very valuable analysis!
>> I looked at a difference in assembly code of the drvsize function produced by
>> gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
>> places the params array and the sectors variable in a different order for
>> different options. One idea is that if BIOS actually writes beyond the end
>> of
>> the array, then in one case it could be harmless (overwrites the sector
>> variable), but in the other case it could be more harmful.
>> I found a document that suggests a possibility of BIOS writing more bytes to
>> the
>> array than its current size of 0x42:
>> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
>>
>> Of course, the size of the array is passed to BIOS at the start of the array
>> and
>> so a _non-buggy_ BIOS should not write beyond the array, but we live in a
>> non-perfect world.
>
> Hmm, I think we've had to do a similar workaround in the past for a different
> BIOS call (SMAP maybe?). However, I do have one request, can we declare an
> actual structure instead of a silly char array? Then we can remove the weird
> casts with offsets into it, etc. Having an actual struct would be far more
> readable and less bug-prone.
>
I am all for this.
Unfortunately. ENOTIME to do this properly at the moment.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 24/10/2011 14:59, John Baldwin wrote:
> On Saturday, October 22, 2011 12:31:25 pm Luchesar V. ILIEV wrote:
>> Speaking of that, and in the context of the recursion that svnversion
>> does, something else comes to my mind...
>>
>> svnversion is currently executed in ${SRCDIR}/sys, so the revision
>> number is relevant only to the kernel sources. But FreeBSD is not just a
>> kernel, unlike Linux, so wouldn't it make more sense to actually check
>> the revision directly at ${SRCDIR}, thus catching possible different
>> revisions in other parts of the base system source tree?
>
> Please no. That makes svnversion take a _lot_ longer. We used to do that,
> but changed it. Also, the kernel build does not use any sources outside
> of sys/, so for the kernel an svnversion of sys/ is perfectly reasonable.
>
Sorry, it's my fault not noticing that it used to be that way. I also
guess that the topic has been discussed, so I'm sure all the pros and
cons have been well weighted. Thanks for the clarification.
Cheers,
Luchesar
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
> on 24/10/2011 16:41 John Baldwin said the following:
> > On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
> >> on 23/10/2011 18:27 Dennis Koegel said the following:
> >>> On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
> Working offline with Dennis, we found that changing the CFLAGS in
> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially
> reverting
> an earlier commit) fixed gptboot. The next test for someone to do would
> be to
> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it.
> >>>
> >>> More test results:
> >>>
> >>> gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
> >>> -fno-unit-at-a-time \
> >>> -mno-align-long-strings -mrtd [from before r225530]: Boots OK
> >>> gcc -Os -mrtd: Boots OK
> >>> gcc -O1 -mrtd: Fails
> >>> gcc -O1: Fails
> >>> gcc -O0: Fails
> >>> gcc -Os: Boots OK
> >>>
> >>> clang -O1: Fails
> >>> clang -Os: Fails
> >>> clang -Oz: Fails
> >>>
> >>> I've put some printf()s into gpt{,boot}.c to trace where the reboot is
> >>> triggered. It appears to be in drvsize() (called from gptread()). OTOH
> >>> the debug output may have changed where the problem occurs, I don't
> >>> know about that.
> >>>
> >>> With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
> >>> out what happens. But as for why gcc's magic -Os is required and clang's
> >>> output doesn't work at all, I'm clueless.
> >>
> >> Thank you for your very valuable analysis!
> >> I looked at a difference in assembly code of the drvsize function produced
> >> by
> >> gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
> >> places the params array and the sectors variable in a different order for
> >> different options. One idea is that if BIOS actually writes beyond the
> >> end of
> >> the array, then in one case it could be harmless (overwrites the sector
> >> variable), but in the other case it could be more harmful.
> >> I found a document that suggests a possibility of BIOS writing more bytes
> >> to the
> >> array than its current size of 0x42:
> >> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
> >>
> >> Of course, the size of the array is passed to BIOS at the start of the
> >> array and
> >> so a _non-buggy_ BIOS should not write beyond the array, but we live in a
> >> non-perfect world.
> >
> > Hmm, I think we've had to do a similar workaround in the past for a
> > different
> > BIOS call (SMAP maybe?). However, I do have one request, can we declare an
> > actual structure instead of a silly char array? Then we can remove the
> > weird
> > casts with offsets into it, etc. Having an actual struct would be far more
> > readable and less bug-prone.
> >
>
> I am all for this.
> Unfortunately. ENOTIME to do this properly at the moment.
Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16 bytes
instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an extra
four bytes.
Ah, so the deal is that the device path bit is variable length and the caller is
supposed to set the length on input which we aren't doing. However, we don't
care about the device path stuff anyway, so we can set a smaller input value.
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
on 24/10/2011 18:33 John Baldwin said the following:
> On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
>> on 24/10/2011 16:41 John Baldwin said the following:
>>> On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
[snip]
I found a document that suggests a possibility of BIOS writing more bytes
to the
array than its current size of 0x42:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
Of course, the size of the array is passed to BIOS at the start of the
array and
so a _non-buggy_ BIOS should not write beyond the array, but we live in a
non-perfect world.
>>>
>>> Hmm, I think we've had to do a similar workaround in the past for a
>>> different
>>> BIOS call (SMAP maybe?). However, I do have one request, can we declare an
>>> actual structure instead of a silly char array? Then we can remove the
>>> weird
>>> casts with offsets into it, etc. Having an actual struct would be far more
>>> readable and less bug-prone.
>>>
>>
>> I am all for this.
>> Unfortunately. ENOTIME to do this properly at the moment.
>
> Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16
> bytes
> instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an
> extra
> four bytes.
Yes, that's exactly what I meant above, but probably wasn't clear about that.
> Ah, so the deal is that the device path bit is variable length and the caller
> is
> supposed to set the length on input which we aren't doing. However, we don't
> care about the device path stuff anyway, so we can set a smaller input value.
>
> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
>
> +struct edd_params {
> + uint16_tlen;
> + uint16_tflags;
> + uint32_tcylinders;
> + uint32_theads;
> + uint32_tsectors_per_track;
> + uint64_tsectors;
> + uint32_tsector_size;
sector_size should be uint16_t, I think. Ditto for edd_params_v3 and
edd_params_v4.
sizeof(struct edd_params) should be 30, judging from the specs.
> + uint16_tedd_params_seg;
> + uint16_tedd_params_off;
> +};
Perhaps the structures should be declared __packed (if only just in case)?
Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some
"smarter" way to avoid verbatim duplicates.
Other than these issues the patch looks great!
Perhaps later we could do detailed definitions for things like interface paths
for
various cases, etc.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On Fri, Oct 21, 2011 at 10:47 PM, Doug Barton wrote: > On 10/21/2011 22:42, Craig Rodrigues wrote: >> Hi, >> >> I tried following: >> >> (1) Run svnversion in non-svn directory: >> >> return status == 0 > > Return status isn't everything. :) > >> prints out "exported" > > In my case (1.7) it says "Unversioned directory" > > But my point (which perhaps I should have made more explicit) is that > given the fact that svnversion handles non-svn directories gracefully > it's faster (simpler, etc.) to just run foo=`svnversion` and then make > sure that $foo is rational than it is to run 2 commands. > > Doug Hi, What logic can we use to make sure svnversion returns a rational value? It looks like the output of svnversion for non-svn directories is inconsistent between versions of Subversion. Running a command seems like a better approach than looking for ".svn" directories. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/i386
TB --- 2011-10-24 15:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 15:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-24 15:30:00 - cleaning the object tree TB --- 2011-10-24 15:30:57 - cvsupping the source tree TB --- 2011-10-24 15:30:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-24 15:31:09 - building world TB --- 2011-10-24 15:31:09 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 15:31:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 15:31:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 15:31:09 - SRCCONF=/dev/null TB --- 2011-10-24 15:31:09 - TARGET=i386 TB --- 2011-10-24 15:31:09 - TARGET_ARCH=i386 TB --- 2011-10-24 15:31:09 - TZ=UTC TB --- 2011-10-24 15:31:09 - __MAKE_CONF=/dev/null TB --- 2011-10-24 15:31:09 - cd /src TB --- 2011-10-24 15:31:09 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 15:31:09 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386.i386/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386.i386/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-pretty-print.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386.i386/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-into-ssa.c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-into-ssa.c: In function 'update_ssa': /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-into-ssa.c:2949: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /src/gnu/usr.bin/cc. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-24 17:15:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 17:15:45 - ERROR: failed to build world TB --- 2011-10-24 17:15:45 - 5141.25 user 861.38 system 6345.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 9.0-beta3, cannot boot after succesfull installation
Hello, list. I've been trying to install FreeBSD 9.0-beta3 amd64 on a machine with the following hardware: Motherboard: MSI K8N Neo2-Platinum CPU: AMD Athlon64 3000+ (1800 MHz) RAM: 1 GB (2 x 512 MB) DDR2 Disk: Western Digital Caviar® Green™ 1TB The story is as follows: Before you think it; I disabled IOAPIC in the BIOS as I have an nforce3 chipset for these installation tests (and it's perhaps not even related to this problem). I decided to re-install my "server" box which was running FreeBSD 8.1 x86 after many power outages and corruption on the filesystem. Initially I had only 1x 1TB disk of the model mentioned above. When I, after a succesful installation and using the guided partitioning scheme with GPT, could not boot the machine, I blamed the HDD and went out and bought another 1TB disk. I plugged it in, ran the installer again, same defaults, and same symptom. The symptom is that the PC freezes at the step where it checks connected devices such as HDDs and CDROM. I can not even enter the BIOS. I took the disks out of the machine, put them into another machine, booted up the newest Ubuntu, and ran the following command to clean the beginning of the disks: dd if=/dev/zero of=/dev/sda1 /* for the first disk */ and dd if=/dev/zero of=/dev/sda2 /* for the second disk */ I then put them back into the machine with which I was having problems. It now booted properly, and I could run the installer again. This time, I used MBR partitioning table. I finished the installer, removed the medium and rebooted. Same symptoms as above. PC freezes at the step where it checks connected devices such as HDDs and CDROM. I can not even enter the BIOS. Someone from #bsddev on efnet adviced me to dd-zero-wipe both the start and the end of the disks. To be sure, I ran these dd commands: dd if=/dev/zero of=/dev/sda1 bs=1M/* for the first disk */ dd if=/dev/zero of=/dev/sda2 bs=1M/* for the second disk */ and let them run over the entirety of both the disks; wiping them completely with zeroes. This time with totally cleaned disks, I installed FreeBSD 9.0-beta3 amd64 again with MBR. I decided NOT to try with GPT as I wasn't sure my BIOS was compatible with GUID partition table. I finished the installer, removed the medium and rebooted. Same symptoms as above. PC freezes at the step where it checks connected devices such as HDDs and CDROM. I can not even enter the BIOS. At this point I gave up and installed FreeBSD 8.2 amd64 with no errors and the machine booted and is running FreeBSD happily now. I have included some output here. Unfortunately I don't have a dd output of a non-working MBR install. ### putty# dd if=/dev/ad4 bs=512 count=4 |hd fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c be 1a 7c bf |.1.|..|.| 0010 1a 06 b9 e6 01 f3 a4 e9 00 8a 31 f6 bb be 07 b1 |..1.| 0020 04 38 2f 74 08 7f 75 85 f6 75 71 89 de 80 c3 10 |.8/t..u..uq.| 0030 e2 ef 85 f6 75 02 cd 18 80 fa 80 72 0b 8a 36 75 |u..r..6u| 0040 04 80 c6 80 38 f2 72 02 8a 14 89 e7 8a 74 01 8b |8.r..t..| 0050 4c 02 bb 00 7c f6 06 bd 07 80 74 2d 51 53 bb aa |L...|.t-QS..| 0060 55 b4 41 cd 13 72 20 81 fb 55 aa 75 1a f6 c1 01 |U.A..r ..U.u| 0070 74 15 5b 66 6a 00 66 ff 74 08 06 53 6a 01 6a 10 |t.[fj.f.t..Sj.j.| 0080 89 e6 b8 00 42 eb 05 5b 59 b8 01 02 cd 13 89 fc |B..[Y...| 0090 72 0f 81 bf fe 01 55 aa 75 0c ff e3 be b9 06 eb |r.U.u...| 00a0 11 be d1 06 eb 0c be f0 06 eb 07 bb 07 00 b4 0e || 00b0 cd 10 ac 84 c0 75 f4 eb fe 49 6e 76 61 6c 69 64 |.u...Invalid| 00c0 20 70 61 72 74 69 74 69 6f 6e 20 74 61 62 6c 65 | partition table| 00d0 00 45 72 72 6f 72 20 6c 6f 61 64 69 6e 67 20 6f |.Error loading o| 00e0 70 65 72 61 74 69 6e 67 20 73 79 73 74 65 6d 00 |perating system.| 00f0 4d 69 73 73 69 6e 67 20 6f 70 65 72 61 74 69 6e |Missing operatin| 0100 67 20 73 79 73 74 65 6d 00 90 90 90 90 90 90 90 |g system| 0110 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 || * 01b0 90 90 90 90 90 90 90 90 90 90 90 90 90 80 80 01 || 01c0 01 00 a5 0f ff ff 3f 00 00 00 71 6d 70 74 00 00 |..?...qmpt..| 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 4+0 records in 4+0 records out 2048 bytes transferred in 0.023271 secs (88007 bytes/sec) 0800 It's funny how it reads "Invalid partition table" etc, but the machine *does * work fine. putty% cat dmesg.txt Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2
Re: Panics after AHCI timeouts
On Tue, Oct 18, 2011 at 3:13 PM, Alexey Shuvaev wrote: > On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: >> On 18 October 2011 03:00, Alexey Shuvaev >> wrote: >> > On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote: >> >> Hello list! >> >> >> > Errr... Replying to myself... Ping? Should I file a PR and put it >> > in the back burner? :) >> >> I think filing a PR is a good move. Then just be proactive and poke >> people about it. It'd be good to get this fixed. :) >> > Done, kern/161768. > > Question to the list: does anybody see successful recovery from AHCI > timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 > branch counts also. That is, there are some kernel messages like this: > > ahcich0: Timeout on slot 29 port 0 > ahcich0: is cs ss rs tfd 40 serr > cmd fc17 > > but then AHCI recovers and the system does not panic? I'm seeing these timeouts too on an 8.2-STABLE amd64 r222832 from June 7. The system hangs partially -- or, more precisely, all processes that attempt to access the disk on this channel hang, everything else continues as normal. I suspect a faulty cable, but I don't have physical access to the system to replace parts right now. A panic would be a regression, so I'm holding off updates on that server until AHCI becomes more tolerant and somewhat self-healing. :( > Poking Alexey. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote:
> on 24/10/2011 18:33 John Baldwin said the following:
> > On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
> >> on 24/10/2011 16:41 John Baldwin said the following:
> >>> On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
> [snip]
> I found a document that suggests a possibility of BIOS writing more
> bytes to the
> array than its current size of 0x42:
> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
>
> Of course, the size of the array is passed to BIOS at the start of the
> array and
> so a _non-buggy_ BIOS should not write beyond the array, but we live in a
> non-perfect world.
> >>>
> >>> Hmm, I think we've had to do a similar workaround in the past for a
> >>> different
> >>> BIOS call (SMAP maybe?). However, I do have one request, can we declare
> >>> an
> >>> actual structure instead of a silly char array? Then we can remove the
> >>> weird
> >>> casts with offsets into it, etc. Having an actual struct would be far
> >>> more
> >>> readable and less bug-prone.
> >>>
> >>
> >> I am all for this.
> >> Unfortunately. ENOTIME to do this properly at the moment.
> >
> > Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16
> > bytes
> > instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an
> > extra
> > four bytes.
>
> Yes, that's exactly what I meant above, but probably wasn't clear about that.
>
> > Ah, so the deal is that the device path bit is variable length and the
> > caller is
> > supposed to set the length on input which we aren't doing. However, we
> > don't
> > care about the device path stuff anyway, so we can set a smaller input
> > value.
> >
> > Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
> >
>
> > +struct edd_params {
> > + uint16_tlen;
> > + uint16_tflags;
> > + uint32_tcylinders;
> > + uint32_theads;
> > + uint32_tsectors_per_track;
> > + uint64_tsectors;
> > + uint32_tsector_size;
>
> sector_size should be uint16_t, I think. Ditto for edd_params_v3 and
> edd_params_v4.
> sizeof(struct edd_params) should be 30, judging from the specs.
Oops, yeah.
> > + uint16_tedd_params_seg;
> > + uint16_tedd_params_off;
> > +};
>
> Perhaps the structures should be declared __packed (if only just in case)?
>
> Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in
> some
> "smarter" way to avoid verbatim duplicates.
Yeah, probably so. We will probably never even use them anyway (just as we
don't
use edd_packet_v3 even though we could probably make use of it to avoid some
bounce buffering in the loader).
> Other than these issues the patch looks great!
> Perhaps later we could do detailed definitions for things like interface
> paths for
> various cases, etc.
I doubt we will ever use them.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for testers : ALi/ULi M5261/M5263 ethernet controller
On Sun, Oct 16, 2011 at 05:22:13PM -0700, YongHyeon PYUN wrote: > Hi, > > If you have ALi/ULi M5261/M5263 ethernet controller please try the > patch at the following URL and let me know how it works. > http://people.freebsd.org/~yongari/dc/dc.uli562x.diff > > The patch was generated against latest HEAD and it should be > cleanly applied to latest stable/8 and stable/7. > I committed revised version to HEAD(r226699, r226701). > Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type":
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to ¶ms. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
Thanks!
- D.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/24/2011 10:14, Craig Rodrigues wrote: > On Fri, Oct 21, 2011 at 10:47 PM, Doug Barton wrote: >> On 10/21/2011 22:42, Craig Rodrigues wrote: >>> Hi, >>> >>> I tried following: >>> >>> (1) Run svnversion in non-svn directory: >>> >>>return status == 0 >> >> Return status isn't everything. :) >> >>>prints out "exported" >> >> In my case (1.7) it says "Unversioned directory" >> >> But my point (which perhaps I should have made more explicit) is that >> given the fact that svnversion handles non-svn directories gracefully >> it's faster (simpler, etc.) to just run foo=`svnversion` and then make >> sure that $foo is rational than it is to run 2 commands. >> >> Doug > > > Hi, > > What logic can we use to make sure svnversion returns a rational value? Make sure that the response starts with a number. > It looks like the output of svnversion for non-svn directories is > inconsistent between versions of Subversion. The non-svn responses vary, the svn responses don't. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}), "/usr/src/sys/conf/kern.mk", line 14: if-less endif
On 10/24/11 00:38, Garrett Cooper wrote:
> On Oct 23, 2011, at 3:31 PM, Hartmann, O. wrote:
>
>> Kernel building fails since today when kernel gets compiled via CLANG:
>> --
> stage 2.1: cleaning up the object tree
>> --
>> cd /usr/obj/usr/src/sys/THOR; MAKEOBJDIRPREFIX=/usr/obj
>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=native
>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.0-CURRENT
>> amd64 100" INSTALL="sh /usr/src/tools/install.sh"
>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/
>> usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr
>> /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbi
>> n:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.amd64/make
>> KERNEL=kernel cleandir
>> "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional
>> (${FREEBSD_GCC})
>> "/usr/src/sys/conf/kern.mk", line 14: if-less endif
>> make: fatal errors encountered -- cannot continue
>> *** Error code 1
>> Stop in /usr/src.
>> *** Error code 1
>> Stop in /usr/src.
> It was noted not too long ago on the commit list as well; r226665 caused the
> breakage.
> -Garrett___
>
So, this is by intention?
When does the problem disappear, so folks building FreeBSD with CLANG
are again capable of building a world and kernel?
Regards,
Oliver
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard
On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: I have installed FreeBSD 9.0 RC1 . During installation and boots , and ( as root ) console mode , both USB keyboard and mouse are working . When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of them are becoming frozen . Detach and attach of mouse are detected , but input is not possible . PS/2 mouse is also not working . I did not check PS/2 keyboard . Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is returning to root prompt . KDE is staying as it is after displaying of hard disk symbol and then it is waiting there . Gnome is displaying all the parts , but no input possibility . Fluxbox is displaying its window , but no input possibility . It seems that X is NOT able to register dbus related parts ( understood from messages left on the screen after discontinuation ) . On the same computer , I have installed Fedora 15 and everything is working as expected , means there is no any hardware problem . Has this computer successfully run other versions of FreeBSD with X? I seem to recall there can be odd interactions with hald, xorg.conf, and others. Some googling brings up http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover many of the relevant issues. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh installed Freebsd 9 don't boot from hd
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
> On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
>> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
>
> GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type":
>
>v86.ds = VTOPSEG(params);
>v86.esi = VTOPOFF(params);
>
> Changed this to ¶ms. Also changed sector_size to uint16_t as noted
> by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well. Unfortunately,
I don't know how to go about it, but I'm hopeful to be able to figure it out
with some basic instructions. I'm currently running a fresh RC1 install, and
I'm able to boot the system if I set the BIOS to IDE mode, rather than AHCI.
Any help would be much appreciated,
Gunnar___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard
On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: I have installed FreeBSD 9.0 RC1 . During installation and boots , and ( as root ) console mode , both USB keyboard and mouse are working . When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of them are becoming frozen . Detach and attach of mouse are detected , but input is not possible . PS/2 mouse is also not working . I did not check PS/2 keyboard . Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is returning to root prompt . KDE is staying as it is after displaying of hard disk symbol and then it is waiting there . Gnome is displaying all the parts , but no input possibility . Fluxbox is displaying its window , but no input possibility . It seems that X is NOT able to register dbus related parts ( understood from messages left on the screen after discontinuation ) . On the same computer , I have installed Fedora 15 and everything is working as expected , means there is no any hardware problem . The same symptoms happen if X is configured to use hald for input device detection but hald is not running. The easy way to test that is to put Option "AutoAddDevices" "Off" in the ServerLayout section. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: aliasing (or renaming) kern.geom.debugflags
On Mon, 24 Oct 2011, Andrey V. Elsukov wrote: On 24.10.2011 1:54, Arnaud Lacombe wrote: NOTE Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. This is stale message. boot0cfg might work without this. On a *mounted* disk? Surely that qualifies as an "open" for the purposes of the check. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}), "/usr/src/sys/conf/kern.mk", line 14: if-less endif
Hi,
On Mon, Oct 24, 2011 at 6:23 PM, Hartmann, O.
wrote:
> On 10/24/11 00:38, Garrett Cooper wrote:
>> On Oct 23, 2011, at 3:31 PM, Hartmann, O. wrote:
>>
>>> Kernel building fails since today when kernel gets compiled via CLANG:
>>> --
>> stage 2.1: cleaning up the object tree
>>> --
>>> cd /usr/obj/usr/src/sys/THOR; MAKEOBJDIRPREFIX=/usr/obj
>>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=native
>>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.0-CURRENT
>>> amd64 100" INSTALL="sh /usr/src/tools/install.sh"
>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/
>>> usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr
>>> /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbi
>>> n:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.amd64/make
>>> KERNEL=kernel cleandir
>>> "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional
>>> (${FREEBSD_GCC})
>>> "/usr/src/sys/conf/kern.mk", line 14: if-less endif
>>> make: fatal errors encountered -- cannot continue
>>> *** Error code 1
>>> Stop in /usr/src.
>>> *** Error code 1
>>> Stop in /usr/src.
>> It was noted not too long ago on the commit list as well; r226665 caused the
>> breakage.
>> -Garrett___
>>
>
> So, this is by intention?
> When does the problem disappear, so folks building FreeBSD with CLANG
> are again capable of building a world and kernel?
>
seemed to have been "fixed" by dim@:
commit 2286e401073a60babb3cc8efce52657f6fa92f7e
Author: dim
Date: Mon Oct 24 18:35:16 2011 +
Put in a temporary band-aid to fix kernel builds when CC=clang, after
r226665.
Thanks dim@!
- Arnaud
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard
On Mon, Oct 24, 2011 at 7:46 PM, Warren Block wrote: > On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: > > I have installed FreeBSD 9.0 RC1 . >> >> During installation and boots , and ( as root ) console mode , both USB >> keyboard and mouse are working . >> >> When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of >> them are becoming frozen . >> Detach and attach of mouse are detected , but input is not possible . >> PS/2 mouse is also not working . >> I did not check PS/2 keyboard . >> Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is >> returning to root prompt . >> >> KDE is staying as it is after displaying of hard disk symbol and then it >> is >> waiting there . >> Gnome is displaying all the parts , but no input possibility . >> Fluxbox is displaying its window , but no input possibility . >> >> It seems that X is NOT able to register dbus related parts ( understood >> from >> messages left on the screen after discontinuation ) . >> >> On the same computer , I have installed Fedora 15 and everything is >> working >> as expected , means there is no any hardware problem . >> > > The same symptoms happen if X is configured to use hald for input device > detection but hald is not running. The easy way to test that is to put > Option "AutoAddDevices" "Off" > in the ServerLayout section. > And also : Has this computer successfully run other versions of FreeBSD with X? I seem to recall there can be odd interactions with hald, xorg.conf, and others. Some googling brings up http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover many of the relevant issues. -Ben Kaduk Unfortunately , ( 9.0 RC1 amd64 ) is overwritten by Fedora 15 . On the same computer , from another hard disk : FreeBSD 9.0-Current #13 r220539M Mon Apr 11 Generic amd4 : root : Fluxbox : USB Keyboard and mouse is working . user : KDE 3.5 : USB Keyboard and mouse is working . /etc/rc.conf contains : moused_type = "auto" moused_enable = "YES" hald_enable = "YES" dbus_enable = "YES" This FreeBSD is from http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110411/ The 9.0 RC1 amd64 contained the same statements listed above . Both of them listed starting of hald and dbus without error during booting . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: replacement of ataidle for freebsd 9
23.10.2011 11:12, Eugene Dzhurinsky wrote: In the mentime, can you please advice how can I use camcontrol in order to disable APM for my HDD? @reboot camcontrol idle ada0 -t 300 ; camcontrol idle ada1 -t 300 -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: aliasing (or renaming) kern.geom.debugflags
On 25.10.2011 5:18, Benjamin Kaduk wrote: >>> to allow writing to the MBR, and restore it to 0 afterwards. >> >> This is stale message. boot0cfg might work without this. > > On a *mounted* disk? Surely that qualifies as an "open" for the purposes of > the check. Yes. boot0cfg uses GEOM_PART' control interface and it may write bootcode to the "open" disk. Actually i found bug here and now it is fixed in r226714. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Slow load time to /boot/loader (3rd stage loader)
Hi all,
I have recently installed 9.0-RC1 on my Thinkpad X201 and have noticed
severe (~20 mins) latency to get to the third stage bootloader
(/boot/loader). This is system triple booted with Windows 7 and Arch
Linux using the GRUB 2 bootmanager. FreeBSD is not on a extended
partition, if it matters. I have tested two BIOS disk configurations,
one with AHCI and the other with IDE compatibility mode. IDE mode is
comparatively faster, but still slower than expected (~3 mins). To see
if this was a regression, I installed 8.2, and it has the same exact
effect. Booting off of USB stick loads fine (e.g. the installer). The
following is my notes with the different BIOS configurations with a link
to the verbose dmesgs for each...
With AHCI enabled:
o dmesg output:
http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ahci.log
o Timeline:
~05 mins - Loading /boot/default/loader.conf appears.
~16 mins - /boot/kernel/kernel displayed.
~20 mins - Welcome to FreeBSD boot prompt.
With IDE compatibility enabled:
o dmesg output:
http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ide.log
o Timeline:
~02 mins - Loading /boot/default/loader.conf and
/boot/kernel/kernel is displayed at once.
~03 mins - Welcome to FreeBSD boot prompt is displayed.
After the boot prompt, startup is normal with no slowdowns to the login
prompt.
---
Current BIOS and ECP versions (output from Linux):
---
# dmidecode -s bios-version
6QET52WW (1.22)
# dmidecode -t 11
# dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x0027, DMI type 11, 5 bytes
OEM Strings
String 1: IBM ThinkPad Embedded Controller -[6QHT30WW-1.11]-
---
FreeBSD GRUB2 entry:
---
menuentry "FreeBSD 9.0-RC1" {
insmod ufs2
set root=(hd0,3)
chainloader +1
}
Any guidance to determine the slow down of this loading problem would be
great.
Thank you for your time...
Cheers,
-John Kuczewski
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-beta3, cannot boot after succesfull installation
Hi, Just because I'd like to ensure this doesn't get lost, would you please do an MBR install of 9.0-RELEASE on another disk, and then plug that in as a slave to the 8.x install? Do you have a USB<->SATA adapter, so you can attach the disk after boot? What I think will help the developers; * getting a copy of the first couple of kilobytes of the 9.0 MBR disk, so the 9.0 and 8.x MBR/boot/partition table stuff can be compared; * Does the system hang when it's the first disk, or _any_ disk? * If we're lucky, the disk will only hang if its the first disk - so we can try installing 8.x bootblocks on the 9.x disk and see if it works; * If we're unlucky and the 9.0 installed disk hangs when plugged in whether it's the boot disk or not - if it attaches as a USB disk (after the 8.x install is done) you can try putting the 8.x bootblocks on and see if the system boots. I doubt you'll be the only person with this problem so thankyou for bringing it to the FreeBSD lists - I bet for every one of you there's 99 others who would try, see it fail and give up without telling the rest of the FreeBSD community. :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: aliasing (or renaming) kern.geom.debugflags
In message , Benjamin Kaduk writes: >On Mon, 24 Oct 2011, Andrey V. Elsukov wrote: >> This is stale message. boot0cfg might work without this. > >On a *mounted* disk? Surely that qualifies as an "open" for the purposes >of the check. The way this used to work before gpart, is that boot0cfg would send a GEOM ctl-message to the MBR-geom asking "Would you please write this boot code ?" Since the MBR-geom was the "owner" of the whole disk, and the one who had it open for writing, it could obviously do so, if it saw fit, and after it had edited its idea about the mbr-partition table into that boot-code. Gpart appearantly does not implement such a ctl message. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: aliasing (or renaming) kern.geom.debugflags
On 25.10.2011 10:08, Poul-Henning Kamp wrote: > The way this used to work before gpart, is that boot0cfg would send > a GEOM ctl-message to the MBR-geom asking "Would you please write this > boot code ?" > > Since the MBR-geom was the "owner" of the whole disk, and the one > who had it open for writing, it could obviously do so, if it saw fit, > and after it had edited its idea about the mbr-partition table into > that boot-code. > > Gpart appearantly does not implement such a ctl message. gpart does it in the same way. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: aliasing (or renaming) kern.geom.debugflags
In message <4ea654f6.1060...@yandex.ru>, "Andrey V. Elsukov" writes: >This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >--enig1B092FDF9A756BE78BC74C01 >Content-Type: text/plain; charset=KOI8-R >Content-Transfer-Encoding: quoted-printable > >On 25.10.2011 10:08, Poul-Henning Kamp wrote: >> The way this used to work before gpart, is that boot0cfg would send >> a GEOM ctl-message to the MBR-geom asking "Would you please write this >> boot code ?" >>=20 >> Since the MBR-geom was the "owner" of the whole disk, and the one >> who had it open for writing, it could obviously do so, if it saw fit, >> and after it had edited its idea about the mbr-partition table into >> that boot-code. >>=20 >> Gpart appearantly does not implement such a ctl message. > >gpart does it in the same way. So why doesn't boot0cfg work ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard
On Mon, Oct 24, 2011 at 6:24 PM, Benjamin Kaduk wrote: > On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: > > I have installed FreeBSD 9.0 RC1 . >> >> During installation and boots , and ( as root ) console mode , both USB >> keyboard and mouse are working . >> >> When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of >> them are becoming frozen . >> Detach and attach of mouse are detected , but input is not possible . >> PS/2 mouse is also not working . >> I did not check PS/2 keyboard . >> Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is >> returning to root prompt . >> >> KDE is staying as it is after displaying of hard disk symbol and then it >> is >> waiting there . >> Gnome is displaying all the parts , but no input possibility . >> Fluxbox is displaying its window , but no input possibility . >> >> It seems that X is NOT able to register dbus related parts ( understood >> from >> messages left on the screen after discontinuation ) . >> >> On the same computer , I have installed Fedora 15 and everything is >> working >> as expected , means there is no any hardware problem . >> > > Has this computer successfully run other versions of FreeBSD with X? > I seem to recall there can be odd interactions with hald, xorg.conf, and > others. Some googling brings up > http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover > many of the relevant issues. > > -Ben Kaduk > The above problem has occurred in 9.0 RC1 amd64 . In the same computer , I have installed 9.0 i386 . USB Mouse and Keyboard are working very well in console mode and in Fluxbox . In both ( amd64 and i386 ) of the installations , /etc/rc.conf contain the following statements : moused_type = "auto" moused_enable = "YES" hald_enable = "YES" dbus_enable = "YES" There are no any generated X configuration file . Both of them listed starting of hald and dbus without error during booting . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
