Re: make release broken
On 5/18/2010 1:39 AM, Garrett Cooper wrote: On Mon, May 17, 2010 at 10:35 PM, Rob Farmer rfar...@predatorlabs.net wrote: Hi, make release is broken on current. Seems to be related to the lzma import. This is on i386: cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo test.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo cpio.lo find.lo minigzip.lo sed.lo arp.lo ppp.lo sysinstall.lo usbconfig.lo -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -lbsdxml -larchive -lbz2 -lusb -ljail /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x1e6): In function `archive_compressor_xz_init': : undefined reference to `lzma_lzma_preset' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x263): In function `archive_compressor_xz_init': : undefined reference to `lzma_alone_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x2c9): In function `archive_compressor_xz_init': : undefined reference to `lzma_stream_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x3ba): In function `drive_compressor': : undefined reference to `lzma_code' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x418): In function `drive_compressor': : undefined reference to `lzma_memusage' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x640): In function `archive_compressor_xz_finish': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9e8): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA1_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa2e): In function `archive_write_mtree_finish_entry': : undefined reference to `RIPEMD160_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa78): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe43): In function `archive_write_mtree_data': : undefined reference to `SHA1_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe63): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe8b): In function `archive_write_mtree_data': : undefined reference to `RIPEMD160_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1297): In function `archive_write_mtree_header': : undefined reference to `SHA1_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12c7): In function `archive_write_mtree_header': : undefined reference to `RIPEMD160_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12f4): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x152): In function `xz_lzma_bidder_init': : undefined reference to `lzma_alone_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x18c): In function `xz_lzma_bidder_init': : undefined reference to `lzma_stream_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x2b1): In function `xz_filter_close': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x567): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Stop in /usr/src/release. libopenssl and libmd bits are missing too. Thanks, -Garrett This URL looks to be the problem you are seeing above. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=20426+0+current/freebsd-current -- jhell ___ 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: make release broken
Rob Farmer wrote: Hi, make release is broken on current. Seems to be related to the lzma import. This is on i386: .. : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x567): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 I saw the same on my amd64 8.0-RELEASE, inside a chroot, building another 8.0-RELEASE. The end of my log below (all I kept, sorry, I'll give it another run now, at the time I assumed it was something wrong in my box). ext+0x392): In function `drive_compressor': : undefined reference to `lzma_code' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x3eb): In function `drive_compressor': : undefined reference to `lzma_memusage' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x5cf): In function `archive_compressor_xz_finish': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x96a): In function `archive_write_mtree_finish_entry': : undefined reference to `RIPEMD160_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9b0): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA1_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9eb): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd36): In function `archive_write_mtree_data': : undefined reference to `SHA1_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd50): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd70): In function `archive_write_mtree_data': : undefined reference to `RIPEMD160_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1204): In function `archive_write_mtree_header': : undefined reference to `SHA1_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1238): In function `archive_write_mtree_header': : undefined reference to `RIPEMD160_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1268): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x178): In function `xz_lzma_bidder_init': : undefined reference to `lzma_alone_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x1a5): In function `xz_lzma_bidder_init': : undefined reference to `lzma_stream_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x2a9): In function `xz_filter_close': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x560): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.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
Re: AESNI driver and fpu_kern KPI
On Sat, May 15, 2010 at 01:04:01PM +0300, Kostik Belousov wrote:
Hello,
please find at http://people.freebsd.org/~kib/misc/aesni.1.patch the
combined patch, containing the fpu_kern KPI and Intel AESNI crypto(9)
driver. I did development and some testing on the hardware generously
provided by Sentex Communications to Netperf cluster.
Nice work. Few comments:
- Could you modify this chunk in padlock.c:
+ td = curthread;
+ error = fpu_kern_enter(td, ses-ses_fpu_ctx);
+ if (error != 0)
+ goto out;
error = padlock_hash_setup(ses, macini);
+ fpu_kern_leave(td, ses-ses_fpu_ctx);
+ out:
To something without goto, eg.:
td = curthread;
error = fpu_kern_enter(td, ses-ses_fpu_ctx);
if (error == 0) {
error = padlock_hash_setup(ses, macini);
fpu_kern_leave(td, ses-ses_fpu_ctx);
}
- I see that in sys/dev/random/nehemiah.c you don't check for return
value of fpu_kern_enter(). That's the only place where you ignore it.
Is that intended?
- Unfortunately the driver in its current version can't be used with
IPsec and with GELI where authentication is enabled. This is because
the driver doesn't support sessions where both encryption and
authentication is defined. Do you have plans to change it?
I saw that you based crypto(9) bits on padlock, which does support
sessions with authentication by calculating hashes in software.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
p...@freebsd.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgptFXEkt9czc.pgp
Description: PGP signature
Re: AESNI driver and fpu_kern KPI
On Tue, May 18, 2010 at 05:30:19PM +0200, Pawel Jakub Dawidek wrote:
On Sat, May 15, 2010 at 01:04:01PM +0300, Kostik Belousov wrote:
Hello,
please find at http://people.freebsd.org/~kib/misc/aesni.1.patch the
combined patch, containing the fpu_kern KPI and Intel AESNI crypto(9)
driver. I did development and some testing on the hardware generously
provided by Sentex Communications to Netperf cluster.
Nice work. Few comments:
- Could you modify this chunk in padlock.c:
+ td = curthread;
+ error = fpu_kern_enter(td, ses-ses_fpu_ctx);
+ if (error != 0)
+ goto out;
error = padlock_hash_setup(ses, macini);
+ fpu_kern_leave(td, ses-ses_fpu_ctx);
+ out:
To something without goto, eg.:
td = curthread;
error = fpu_kern_enter(td, ses-ses_fpu_ctx);
if (error == 0) {
error = padlock_hash_setup(ses, macini);
fpu_kern_leave(td, ses-ses_fpu_ctx);
}
Done.
- I see that in sys/dev/random/nehemiah.c you don't check for return
value of fpu_kern_enter(). That's the only place where you ignore it.
Is that intended?
No, thank you, fixed.
- Unfortunately the driver in its current version can't be used with
IPsec and with GELI where authentication is enabled. This is because
the driver doesn't support sessions where both encryption and
authentication is defined. Do you have plans to change it?
I saw that you based crypto(9) bits on padlock, which does support
sessions with authentication by calculating hashes in software.
My goal was to develop fpu_kern_enter() KPI. I used the AESNI as an
opportunity to test the KPI in real application. I may consider adding
software-implemented authentification sometime later. I would not object
if anybody do this instead of me.
Since you are there, I want to confirm that you do not have objections
against your copyright left in aesni.c. The file was copied from
padlock.c and I felt that removing the copyright is wrong.
Updated patch, that also includes some other changes, mainly additions
to fpu_kern() KPI, that were discussed/requested by Fabien Thomas,
is at http://people.freebsd.org/~kib/misc/aesni.2.patch.
Thank you for your comments.
pgp8b5Us7q8yA.pgp
Description: PGP signature
ffs_copyonwrite panics
Hi, I've been using -CURRENT last update in February for quite a long time and few weeks ago decided to finally update it. The update was quite unfortunate as system became very unstable: it just hangs few times a day and panics sometimes. Some things can be reproduced, some cannot. Reproducible ones: 1. background fsck always makes system hang 2. system crashes on operations with nullfs mounts (disabled that for now) The most annoying one is ffs_copyonwrite panic which I cannot reproduce. The thing is that if I will run 'startx' on it with some X apps it will panic just in few minutes. When I leave the box with nearly no stress (just use it as internet gateway for my laptop) it behaves a little better but will eventually crash in few hours anyway. The even more annoying thing is that when I cannot save the dump, because when the system boots and runs 'savecore' it leads to fss_copyonwrite panic as well. The panic happens when about 90% complete (as seem via ctrl-t). Any ideas how to debug and get rid of this issue? System arch is amd64. I don't know what other details could be useful. Roman Bogorodskiy signature.asc Description: Digital signature
Re: AESNI driver and fpu_kern KPI
- Unfortunately the driver in its current version can't be used with IPsec and with GELI where authentication is enabled. This is because the driver doesn't support sessions where both encryption and authentication is defined. Do you have plans to change it? I saw that you based crypto(9) bits on padlock, which does support sessions with authentication by calculating hashes in software. My goal was to develop fpu_kern_enter() KPI. I used the AESNI as an opportunity to test the KPI in real application. I may consider adding software-implemented authentification sometime later. I would not object if anybody do this instead of me. Today I've tested the patch with the same issue with IPsec, i've quickly re-included the same keyed hash function than padlock to test, tomorrow I will test again and I will post a patch if it works well. A minor things: aesni only compile as a module. Another idea for Sha1 would be to integrate the new version from intel http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1/ but it seems the 32bits version is not available at this time (and same licencing issue). Regards, Fabien ___ 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: ffs_copyonwrite panics
Roman Bogorodskiy bogorods...@gmail.com wrote: I've been using -CURRENT last update in February for quite a long time and few weeks ago decided to finally update it. The update was quite unfortunate as system became very unstable: it just hangs few times a day and panics sometimes. Some things can be reproduced, some cannot. Reproducible ones: 1. background fsck always makes system hang 2. system crashes on operations with nullfs mounts (disabled that for now) The most annoying one is ffs_copyonwrite panic which I cannot reproduce. The thing is that if I will run 'startx' on it with some X apps it will panic just in few minutes. When I leave the box with nearly no stress (just use it as internet gateway for my laptop) it behaves a little better but will eventually crash in few hours anyway. The even more annoying thing is that when I cannot save the dump, because when the system boots and runs 'savecore' it leads to fss_copyonwrite panic as well. The panic happens when about 90% complete (as seem via ctrl-t). Any ideas how to debug and get rid of this issue? System arch is amd64. I don't know what other details could be useful. I'm not familiar with the background fsck issue, but if the nullfs panic looks like this one, there's a fair chance it's already fixed: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0x82412f14 stack pointer = 0x28:0xff803e564620 frame pointer = 0x28:0xff803e564770 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1825 (jail) panic: from debugger cpuid = 0 Uptime: 38s Dumping 1992 MB (5 chunks) chunk 0: 1MB (155 pages) ... ok chunk 1: 1990MB (509345 pages) 1974 [...] 6 ... ok chunk 2: 2MB (273 pages) ... ok chunk 3: 1MB (184 pages) #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0x803c506f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x803c546c in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0x801f6e77 in db_panic (addr=Variable addr is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0x801f7281 in db_command (last_cmdp=0x808bfd80, cmd_table=Variable cmd_table is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0x801f74d0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0x801f9429 in db_trap (type=Variable type is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0x803f3c25 in kdb_trap (type=12, code=0, tf=0xff803e564570) at /usr/src/sys/kern/subr_kdb.c:535 #8 0x8062ad9d in trap_fatal (frame=0xff803e564570, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:773 #9 0x8062b0fc in trap_pfault (frame=0xff803e564570, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:694 #10 0x8062b8ff in trap (frame=0xff803e564570) at /usr/src/sys/amd64/amd64/trap.c:451 #11 0x80611f33 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #12 0x82412f14 in null_bypass (ap=0xff803e564780) at /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:269 #13 0x80448104 in vgonel (vp=0xff0005e05780) at vnode_if.h:1099 #14 0x8044835e in vrecycle (vp=0xff0005e05780, td=Variable td is not available. ) at /usr/src/sys/kern/vfs_subr.c:2505 #15 0x82412e6f in null_inactive (ap=Variable ap is not available. ) at /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:665 #16 0x80444ff8 in vinactive (vp=0xff0005e05780, td=0xff00054743e0) at vnode_if.h:807 #17 0x804495dd in vputx (vp=0xff0005e05780, func=2) at /usr/src/sys/kern/vfs_subr.c:2226 #18 0x8043e1ae in lookup (ndp=0xff803e564a50) at /usr/src/sys/kern/vfs_lookup.c:905 #19 0x8043eef7 in namei (ndp=0xff803e564a50) at /usr/src/sys/kern/vfs_lookup.c:269 #20 0x8044ec86 in kern_accessat (td=0xff00054743e0, fd=-100, path=0x800537000 Address 0x800537000 out of bounds, pathseg=Variable pathseg is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2140 #21 0x8062b21d in syscall (frame=0xff803e564c80) at /usr/src/sys/amd64/amd64/trap.c:946 #22 0x80612211 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:374 #23 0x00080050e5ec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) I got it reproducible with: FreeBSD 9.0-CURRENT #66 r+3fe665b: Fri May 14 17:45:10 CEST 2010 f...@r500.local:/usr/obj/usr/src/sys/ZOEY amd64 but
HEAD can't bring up APs on Intel LC5528(Jasper Forest)
I'm trying to bring up a new board based on Intel's Jasper Forest x86 processor. I can boot a kernel without SMP without any problems, but FreeBSD is not able to start up the Application Processors if I enable SMP. The error message that I get is: AP #2 (PHY# 2) failed! panic y/n? [y] This was a i386 kernel built from HEAD as May 2nd or so. It's not always PHY#2. Some number of APs manage to start up correctly, but one usually fails. I have observed one instance where all of the APs came up properly, so it seems as though there's some kind of race that I stand a very good chance of losing at least one time in seven tries. If I disable all but one AP through device.hints I stand a pretty good chance of successfully starting that AP and booting correctly. I've been banging my head against the wall for a while now and all indications are that the AP never starts at all. I enabled the CHECK_POINTS compile-time option and and nothing ever gets written to the CMOS for the AP that fails to start. Writing to the CMOS is the second thing that the AP does after doing a cli so it's a good bet that the AP never hits that code. Linux (version 2.6.28-11) is able to boot and start the APs just fine. My suspicion is that Linux is explicitly configuring something that FreeBSD is trusting the BIOS to do. We do have the reference board around, but we're having trouble getting the original Intel BIOS programmed into it. If we can get that working again I'll let you know whether FreeBSD can boot on it. If anybody can offer any hints or ideas for debugging this it'd be greatly appreciated, as right now I'm reduced to grasping at straws. ___ 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: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
What if you use amd64, have you tried that? Low level code is different. Interesting however, maybe I can get access to one around here, will see. Jack On Tue, May 18, 2010 at 2:32 PM, Ryan Stone ryst...@gmail.com wrote: I'm trying to bring up a new board based on Intel's Jasper Forest x86 processor. I can boot a kernel without SMP without any problems, but FreeBSD is not able to start up the Application Processors if I enable SMP. The error message that I get is: AP #2 (PHY# 2) failed! panic y/n? [y] This was a i386 kernel built from HEAD as May 2nd or so. It's not always PHY#2. Some number of APs manage to start up correctly, but one usually fails. I have observed one instance where all of the APs came up properly, so it seems as though there's some kind of race that I stand a very good chance of losing at least one time in seven tries. If I disable all but one AP through device.hints I stand a pretty good chance of successfully starting that AP and booting correctly. I've been banging my head against the wall for a while now and all indications are that the AP never starts at all. I enabled the CHECK_POINTS compile-time option and and nothing ever gets written to the CMOS for the AP that fails to start. Writing to the CMOS is the second thing that the AP does after doing a cli so it's a good bet that the AP never hits that code. Linux (version 2.6.28-11) is able to boot and start the APs just fine. My suspicion is that Linux is explicitly configuring something that FreeBSD is trusting the BIOS to do. We do have the reference board around, but we're having trouble getting the original Intel BIOS programmed into it. If we can get that working again I'll let you know whether FreeBSD can boot on it. If anybody can offer any hints or ideas for debugging this it'd be greatly appreciated, as right now I'm reduced to grasping at straws. ___ 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-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: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
amd64 exhibits the same problem, except that it's not even polite and panics without even asking. ___ 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: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
LOL, ok, I'm beating the bushes here Ryan, and I think I can get a system although it may be a day or two. Will let you know. Jack On Tue, May 18, 2010 at 4:40 PM, Ryan Stone ryst...@gmail.com wrote: amd64 exhibits the same problem, except that it's not even polite and panics without even asking. ___ 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: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
On Tue, 18 May 2010 19:40:13 -0400 Ryan Stone ryst...@gmail.com wrote: amd64 exhibits the same problem, except that it's not even polite and panics without even asking. Could you please try disabling legacy USB device support in BIOS if such an option is provided in your BIOS setup and see if that changes anything? -- Alexander Kabaev signature.asc Description: PGP signature
