Re: [CFT] Need Testers for: sysutils/bsdconfig
22.06.2012 10:50, Ron McDowell пишет: Again, thank you very much for testing this new software. P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. I'm one of the coauthors of this code, and I am here on -stable. As stated, this port will only run on 9.0-RELEASE and later. Please give it a try! Thanks! I've tried it on installed 9.0-STABLE system. 1. At the moment, the documentation does not install: Could not install package en-freebsd-doc (pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/en-freebsd-doc.tbz' by URL) 2. For system running single gmirror gm0 consisting of 2 whole disks ada0 and ada1, 'Label allocated disk partitions' offers only ada0 and ada1 for disklabel editor and not gm0. And disklabel editor shows empty list of partitions. 3. Similar for FDISK Partition Editor (ada0/ada1 and not gm0 for choise), but Partition Editor presents whole disk space as 'unused' Note that current SATA disk prices and quality offers no choice for servers other that some kind of RAID. 4. Networking Devices configuration presents lagg0 device as unknown network interface type. It should provide descriptive string like 'Link aggregation/failover'. 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. 6. Same for ipfw0 pseudo-interface. 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. For example, it should be possible to configure new vlan interface while NFS mount uses another vlan. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server through two-step procedure - first try to edit, then clear the address. It should be more obvious at first. That's enough for this time :-) Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 12:07 AM, Eugene Grosbein wrote: 22.06.2012 10:50, Ron McDowell пишет: Again, thank you very much for testing this new software. P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. I'm one of the coauthors of this code, and I am here on -stable. As stated, this port will only run on 9.0-RELEASE and later. Please give it a try! Thanks! I've tried it on installed 9.0-STABLE system. First, thank you for testing! 1. At the moment, the documentation does not install: Could not install package en-freebsd-doc (pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/en-freebsd-doc.tbz' by URL) Ok. Thx. A PR should be filed against bsdinstall (since bsdconfig is simply linking to bsdinstall docsinstall for that menu item and is not actually responsible for the bug). 2. For system running single gmirror gm0 consisting of 2 whole disks ada0 and ada1, 'Label allocated disk partitions' offers only ada0 and ada1 for disklabel editor and not gm0. And disklabel editor shows empty list of partitions. Ok, Thx. This too is not part of bsdconfig, but is linked to sade(8). NOTE: Documentation Installation and Disk Partition/Label are the only two modules that are pointed to other tools (the former linked to bsdinstall docsinstall and the latter linked to sade). The goal for this is to replace sade (which is not geom compatible) with a new tool. This is on the community's to-do list. 3. Similar for FDISK Partition Editor (ada0/ada1 and not gm0 for choise), but Partition Editor presents whole disk space as 'unused' Note that current SATA disk prices and quality offers no choice for servers other that some kind of RAID. Again, this is because sade(8) is not geom compatible. 4. Networking Devices configuration presents lagg0 device as unknown network interface type. It should provide descriptive string like 'Link aggregation/failover'. It's on my to-do list to change the way descriptions are calculated. Currently, I've got a static hard-coded list of descriptions. Someone recommended that there was a way to get this information from sysctl. 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. Did I completely disallow it? I'll have to re-check -- I thought that I had made it so that you could view/edit the configuration but that the warning says that changes will not become effective until you either reboot or visit the menu again when no NFS mounts are active. For example, it should be possible to configure new vlan interface while NFS mount uses another clan. Do you know of a handy way of determining which NFS mount is using which network interface? And further, is there a handy way of traversing the route path to determine that one interface isn't required as an intermediary transit device? (meaning: can one truly ever know that making a new configuration active on any interface could not potentially drop your entire machine from the net with hung NFS mounts?) Many months of testing in the lab produced no less than 6 edge-cases where -- if a network link or route is modified when NFS mounts are active -- the machine can enter an unstable/unusable state. So we decided to err on the side of caution when it came to allowing settings to be made-active when NFS mounts are active. I'm not against improving the code, but I'm wondering if it wouldn't be safer to stick to disallowing any/all changes from being made-active (while allowing viewing/editing without making-active) when NFS mounts are active. NOTE: There are other safe-guards too. For example, if you're logged in via SSH and using X11 forwarding while passing the -X flag (to use Xdialog(1)), you are disallowed from making a new hostname active (you can change the hostname, but not make it active) because that would cause the very next iteration of Xdialog(1) to fail due to a surreptitious X authority revocation based on the hostname-change in mid-session. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server
Re: [CFT] Need Testers for: sysutils/bsdconfig
22.06.2012 14:37, Devin Teske пишет: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. Did I completely disallow it? Yes. I'll have to re-check -- I thought that I had made it so that you could view/edit the configuration but that the warning says that changes will not become effective until you either reboot or visit the menu again when no NFS mounts are active. For example, it should be possible to configure new vlan interface while NFS mount uses another clan. Do you know of a handy way of determining which NFS mount is using which network interface? And further, is there a handy way of traversing the route path to determine that one interface isn't required as an intermediary transit device? (meaning: can one truly ever know that making a new configuration active on any interface could not potentially drop your entire machine from the net with hung NFS mounts?) Many months of testing in the lab produced no less than 6 edge-cases where -- if a network link or route is modified when NFS mounts are active -- the machine can enter an unstable/unusable state. So we decided to err on the side of caution when it came to allowing settings to be made-active when NFS mounts are active. I'm not against improving the code, but I'm wondering if it wouldn't be safer to stick to disallowing any/all changes from being made-active (while allowing viewing/editing without making-active) when NFS mounts are active. NOTE: There are other safe-guards too. For example, if you're logged in via SSH and using X11 forwarding while passing the -X flag (to use Xdialog(1)), you are disallowed from making a new hostname active (you can change the hostname, but not make it active) because that would cause the very next iteration of Xdialog(1) to fail due to a surreptitious X authority revocation based on the hostname-change in mid-session. I'm sure that bsdconfig should emit warnings only but not disallow root to make any needed changes. NFS may use completly unrelated routes/interfaces, X11 may be user over network without ssh -X etc. It's pretty annoying for administrator to fight with tools thinking they know better what root should do. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server through two-step procedure - first try to edit, then clear the address. It should be more obvious at first. Can you have a look at bsdconfig startup_rcconf and see if that's a better way to go about the deletion-process? Or perhaps you're just advocating a helpful message in the text above the menu list that explains how to delete the item? (least amount of work) Again, just a message. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 12:53 AM, Eugene Grosbein wrote: 22.06.2012 14:37, Devin Teske пишет: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. Did I completely disallow it? Yes. I'll have to re-check -- I thought that I had made it so that you could view/edit the configuration but that the warning says that changes will not become effective until you either reboot or visit the menu again when no NFS mounts are active. For example, it should be possible to configure new vlan interface while NFS mount uses another clan. Do you know of a handy way of determining which NFS mount is using which network interface? And further, is there a handy way of traversing the route path to determine that one interface isn't required as an intermediary transit device? (meaning: can one truly ever know that making a new configuration active on any interface could not potentially drop your entire machine from the net with hung NFS mounts?) Many months of testing in the lab produced no less than 6 edge-cases where -- if a network link or route is modified when NFS mounts are active -- the machine can enter an unstable/unusable state. So we decided to err on the side of caution when it came to allowing settings to be made-active when NFS mounts are active. I'm not against improving the code, but I'm wondering if it wouldn't be safer to stick to disallowing any/all changes from being made-active (while allowing viewing/editing without making-active) when NFS mounts are active. NOTE: There are other safe-guards too. For example, if you're logged in via SSH and using X11 forwarding while passing the -X flag (to use Xdialog(1)), you are disallowed from making a new hostname active (you can change the hostname, but not make it active) because that would cause the very next iteration of Xdialog(1) to fail due to a surreptitious X authority revocation based on the hostname-change in mid-session. I'm sure that bsdconfig should emit warnings only but not disallow root to make any needed changes. I'm inclined to agree. FreeBSD should not prevent you from being stupid (as someone once told me). I should change the errors to warnings and allow the user to [potentially] hose their connection given ample warning/chance-to-back-out. NFS may use completly unrelated routes/interfaces, X11 may be user over network without ssh -X etc. Got that one covered actually -- you can tell when a user is using X11 forwarding versus X11 local. It's pretty annoying for administrator to fight with tools thinking they know better what root should do. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server through two-step procedure - first try to edit, then clear the address. It should be more obvious at first. Can you have a look at bsdconfig startup_rcconf and see if that's a better way to go about the deletion-process? Or perhaps you're just advocating a helpful message in the text above the menu list that explains how to delete the item? (least amount of work) Again, just a message. Ok, cool. Thanks again, -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
Re: [CFT] Need Testers for: sysutils/bsdconfig
22.06.2012 15:39, Devin Teske wrote: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). That's driver-dependent. For example, lagg does not presents %desc nor ipfw0 and I suppose pretty many others do not. You could use %desc if it's present and fall back to internal static list otherwise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: [CFT] Need Testers for: sysutils/bsdconfig
5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). That's driver-dependent. For example, lagg does not presents %desc nor ipfw0 and I suppose pretty many others do not. You could use %desc if it's present and fall back to internal static list otherwise. Just something cosmetic but when I add a user when it comes to select the shell it does not have a title like: Select a shell Also it said that my user add failed but it was actually added as uid 1005. I added another user and it stated the uid 1005 when I was creating it but showed 1006 in the summary screen. It also said that adding the user failed. Perhaps I used to short a password as there was no password field entered in /etc/master.passwd twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. //Clay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi(4) IO performance regression, post 8.1
On Thursday, June 21, 2012 10:36:04 pm Charles Owens wrote:
On 6/15/12 8:04 AM, John Baldwin wrote:
On Friday, June 15, 2012 12:28:59 am Charles Owens wrote:
Hello FreeBSD folk,
We're seeing what appears to be a storage performance regression as we
try to move from 8.1 (i386) to 8.3. We looked at 8.2 also and it
appears that the regression happened between 8.1 and 8.2.
Our system is an Intel S5520UR Server with 12 GB RAM, dual 4-core CPUs.
Storage is a LSI MegaSAS 1078 controller (mfi) in a RAID-10
configuration, using UFS + geom_journal for filesystem.
Postgresql performance, as seen via pgbench, dropped by approx 20%.
This testing was done with our usual PAE-enabled kernels. We then went
back to GENERIC kernels and did comparisons using bonnie, results
below. Following that is a kernel boot log.
Notably, we're seeing this regression only with our RAID mfi(4) based
systems. Notably, from looking at FreeBSD source changelogs it appears
that the mfi(4) code has seen some changes since 8.1.
Between 8.1 and 8.2 mfi has not had any significant changes. The only
changes
made to sys/dev/mfi were to add a new constant:
svn diff svn+ssh://svn.freebsd.org/base/releng/8.1/sys/dev/mfi
svn+ssh://svn.freebsd.org/base/releng/8.2/sys/dev/mfi
Index: mfireg.h
===
--- mfireg.h(.../8.1/sys/dev/mfi) (revision 237134)
+++ mfireg.h(.../8.2/sys/dev/mfi) (revision 237134)
@@ -975,7 +975,9 @@
MFI_PD_STATE_OFFLINE = 0x10,
MFI_PD_STATE_FAILED = 0x11,
MFI_PD_STATE_REBUILD = 0x14,
- MFI_PD_STATE_ONLINE = 0x18
+ MFI_PD_STATE_ONLINE = 0x18,
+ MFI_PD_STATE_COPYBACK = 0x20,
+ MFI_PD_STATE_SYSTEM = 0x40
};
union mfi_ld_ref {
The difference in write performance must be due to something else. You
mentioned you are using UFS + gjournal. I think gjournal uses BIO_FLUSH,
so I
wonder if this is related:
r212939 | gibbs | 2010-09-20 19:39:00 -0400 (Mon, 20 Sep 2010) | 61 lines
MFC 212160:
Correct bioq_disksort so that bioq_insert_tail() offers barrier semantic.
Add the BIO_ORDERED flag for struct bio and update bio clients to use it.
The barrier semantics of bioq_insert_tail() were broken in two ways:
o In bioq_disksort(), an added bio could be inserted at the head of
the queue, even when a barrier was present, if the sort key for
the new entry was less than that of the last queued barrier bio.
o The last_offset used to generate the sort key for newly queued bios
did not stay at the position of the barrier until either the
barrier was de-queued, or a new barrier (which updates last_offset)
was queued. When a barrier is in effect, we know that the disk
will pass through the barrier position just before the
blocked bios are released, so using the barrier's offset for
last_offset is the optimal choice.
sys/geom/sched/subr_disk.c:
sys/kern/subr_disk.c:
o Update last_offset in bioq_insert_tail().
o Only update last_offset in bioq_remove() if the removed bio is
at the head of the queue (typically due to a call via
bioq_takefirst()) and no barrier is active.
o In bioq_disksort(), if we have a barrier (insert_point is
non-NULL),
set prev to the barrier and cur to it's next element. Now that
last_offset is kept at the barrier position, this change isn't
strictly necessary, but since we have to take a decision branch
anyway, it does avoid one, no-op, loop iteration in the while
loop that immediately follows.
o In bioq_disksort(), bypass the normal sort for bios with the
BIO_ORDERED attribute and instead insert them into the queue
with bioq_insert_tail(). bioq_insert_tail() not only gives
the desired command order during insertion, but also provides
barrier semantics so that commands disksorted in the future
cannot pass the just enqueued transaction.
sys/sys/bio.h:
Add BIO_ORDERED as bit 4 of the bio_flags field in struct bio.
sys/cam/ata/ata_da.c:
sys/cam/scsi/scsi_da.c
Use an ordered command for SCSI/ATA-NCQ commands issued in
response to bios with the BIO_ORDERED flag set.
sys/cam/scsi/scsi_da.c
Use an ordered tag when issuing a synchronize cache command.
Wrap some lines to 80 columns.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
sys/geom/geom_io.c
Mark bios with the BIO_FLUSH command as BIO_ORDERED.
Sponsored by: Spectra Logic Corporation
Can you try perhaps commenting out
re: disk IO performance regression, post 8.1
On 6/22/12 10:22 AM, John Baldwin wrote:
On Thursday, June 21, 2012 10:36:04 pm Charles Owens wrote:
On 6/15/12 8:04 AM, John Baldwin wrote:
On Friday, June 15, 2012 12:28:59 am Charles Owens wrote:
Hello FreeBSD folk,
We're seeing what appears to be a storage performance regression as we
try to move from 8.1 (i386) to 8.3. We looked at 8.2 also and it
appears that the regression happened between 8.1 and 8.2.
Our system is an Intel S5520UR Server with 12 GB RAM, dual 4-core CPUs.
Storage is a LSI MegaSAS 1078 controller (mfi) in a RAID-10
configuration, using UFS + geom_journal for filesystem.
Postgresql performance, as seen via pgbench, dropped by approx 20%.
This testing was done with our usual PAE-enabled kernels. We then went
back to GENERIC kernels and did comparisons using bonnie, results
below. Following that is a kernel boot log.
Notably, we're seeing this regression only with our RAID mfi(4) based
systems. Notably, from looking at FreeBSD source changelogs it appears
that the mfi(4) code has seen some changes since 8.1.
Between 8.1 and 8.2 mfi has not had any significant changes. The only changes
made to sys/dev/mfi were to add a new constant:
svn diff svn+ssh://svn.freebsd.org/base/releng/8.1/sys/dev/mfi
svn+ssh://svn.freebsd.org/base/releng/8.2/sys/dev/mfi
Index: mfireg.h
===
--- mfireg.h(.../8.1/sys/dev/mfi) (revision 237134)
+++ mfireg.h(.../8.2/sys/dev/mfi) (revision 237134)
@@ -975,7 +975,9 @@
MFI_PD_STATE_OFFLINE = 0x10,
MFI_PD_STATE_FAILED = 0x11,
MFI_PD_STATE_REBUILD = 0x14,
- MFI_PD_STATE_ONLINE = 0x18
+ MFI_PD_STATE_ONLINE = 0x18,
+ MFI_PD_STATE_COPYBACK = 0x20,
+ MFI_PD_STATE_SYSTEM = 0x40
};
union mfi_ld_ref {
The difference in write performance must be due to something else. You
mentioned you are using UFS + gjournal. I think gjournal uses BIO_FLUSH, so I
wonder if this is related:
r212939 | gibbs | 2010-09-20 19:39:00 -0400 (Mon, 20 Sep 2010) | 61 lines
MFC 212160:
Correct bioq_disksort so that bioq_insert_tail() offers barrier semantic.
Add the BIO_ORDERED flag for struct bio and update bio clients to use it.
The barrier semantics of bioq_insert_tail() were broken in two ways:
o In bioq_disksort(), an added bio could be inserted at the head of
the queue, even when a barrier was present, if the sort key for
the new entry was less than that of the last queued barrier bio.
o The last_offset used to generate the sort key for newly queued bios
did not stay at the position of the barrier until either the
barrier was de-queued, or a new barrier (which updates last_offset)
was queued. When a barrier is in effect, we know that the disk
will pass through the barrier position just before the
blocked bios are released, so using the barrier's offset for
last_offset is the optimal choice.
sys/geom/sched/subr_disk.c:
sys/kern/subr_disk.c:
o Update last_offset in bioq_insert_tail().
o Only update last_offset in bioq_remove() if the removed bio is
at the head of the queue (typically due to a call via
bioq_takefirst()) and no barrier is active.
o In bioq_disksort(), if we have a barrier (insert_point is non-NULL),
set prev to the barrier and cur to it's next element. Now that
last_offset is kept at the barrier position, this change isn't
strictly necessary, but since we have to take a decision branch
anyway, it does avoid one, no-op, loop iteration in the while
loop that immediately follows.
o In bioq_disksort(), bypass the normal sort for bios with the
BIO_ORDERED attribute and instead insert them into the queue
with bioq_insert_tail(). bioq_insert_tail() not only gives
the desired command order during insertion, but also provides
barrier semantics so that commands disksorted in the future
cannot pass the just enqueued transaction.
sys/sys/bio.h:
Add BIO_ORDERED as bit 4 of the bio_flags field in struct bio.
sys/cam/ata/ata_da.c:
sys/cam/scsi/scsi_da.c
Use an ordered command for SCSI/ATA-NCQ commands issued in
response to bios with the BIO_ORDERED flag set.
sys/cam/scsi/scsi_da.c
Use an ordered tag when issuing a synchronize cache command.
Wrap some lines to 80 columns.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
sys/geom/geom_io.c
Mark bios with the BIO_FLUSH command as BIO_ORDERED.
Sponsored by: Spectra Logic Corporation
Can you try perhaps commenting out the 'bp-bio_flags |= BIO_ORDERED' line
changed in geom_io.c in 8.2? That would be effectively reverting this
portion
9-STABLE doesn't build with clang/llvm
Anybody else having trouble building r237440 with clang:
/usr/bin/clang -O2 -pipe -I/usr/home/bketchum/kernels/stable-9/lib/libc/includ
e -I/usr/home/bketchum/kernels/stable-9/lib/libc/../../include -I/usr/home/bketc
hum/kernels/stable-9/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/home/b
ketchum/kernels/stable-9/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/home/bketch
um/kernels/obj/stable-9/usr/home/bketchum/kernels/stable-9/lib/libc -I/usr/home/
bketchum/kernels/stable-9/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/
home/bketchum/kernels/stable-9/lib/libc/../../contrib/tzcode/stdtime -I/usr/home
/bketchum/kernels/stable-9/lib/libc/stdtime -I/usr/home/bketchum/kernels/stable-
9/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/home/bketchum/kern
els/stable-9/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Qunu
sed-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-unin
itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautologic
al-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno
-conversion -Wno-switch -Wno-switch-enum -c /usr/home/bketchum/kernels/stable-9/
lib/libc/db/btree/bt_close.c -o bt_close.o
In file included from /usr/home/bketchum/kernels/stable-9/lib/libc/db/btree/bt_c
lose.c:44:
/usr/home/bketchum/kernels/stable-9/lib/libc/../../include/stdlib.h:82:1: error:
unknown type name '_Noreturn'
_Noreturn void abort(void);
^
/usr/home/bketchum/kernels/stable-9/lib/libc/../../include/stdlib.h:82:11: error
:
expected identifier or '('
_Noreturn void abort(void);
^
/usr/home/bketchum/kernels/stable-9/lib/libc/../../include/stdlib.h:92:1: error:
unknown type name '_Noreturn'
_Noreturn void exit(int);
^
/usr/home/bketchum/kernels/stable-9/lib/libc/../../include/stdlib.h:92:11: error
:
expected identifier or '('
_Noreturn void exit(int);
^
/usr/home/bketchum/kernels/stable-9/lib/libc/../../include/stdlib.h:151:1: error
:
unknown type name '_Noreturn'
_Noreturn void _Exit(int);
^
/usr/home/bketchum/kernels/stable-9/lib/libc/../../include/stdlib.h:151:11: erro
r:
expected identifier or '('
_Noreturn void _Exit(int);
^
In file included from /usr/home/bketchum/kernels/stable-9/lib/libc/db/btree/bt_c
lose.c:46:
/usr/home/bketchum/kernels/stable-9/lib/libc/../../include/unistd.h:482:20: erro
r:
expected function body after function declarator
pid_t vfork(void) __returns_twice;
^
7 errors generated.
*** Error code 1
Stop in /usr/home/bketchum/kernels/stable-9/lib/libc.
*** Error code 1
Stop in /usr/home/bketchum/kernels/stable-9.
*** Error code 1
Stop in /usr/home/bketchum/kernels/stable-9.
*** Error code 1
Stop in /usr/home/bketchum/kernels/stable-9.
*** Error code 1
Stop in /usr/home/bketchum/kernels/stable-9.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE doesn't build with clang/llvm
On Fri, Jun 22, 2012 at 04:47:27AM -0700, Dr. Baud wrote: Anybody else having trouble building r237440 with clang: ... I did not have trouble (on i386): FreeBSD g1-227.catwhisker.org 9.0-STABLE FreeBSD 9.0-STABLE #195 237440M: Fri Jun 22 05:22:20 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpRoufQi9uel.pgp Description: PGP signature
KMS on Sandy bridge error device_attach
Hi, I just updated my world to try kms which has recently been merged into stable. However I get this when kldload'ing i915kms: drmn0: Intel SandyBridge (M) on vgapci0 info: [drm] MSI enabled 1 message(s) error: [drm:pid1295:drm_load] *ERROR* Card isn't AGP, or couldn't initialize AGP. device_attach: drmn0 attach returned 12 CPU is this model: CPU: Intel(R) Xeon(R) CPU E31260L @ 2.40GHz (2400.07-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Is this model supposed to work with the current code? Best regards Riggs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: KMS on Sandy bridge error device_attach
On Fri, Jun 22, 2012 at 07:44:52PM +0200, Thomas Zander wrote: Hi, I just updated my world to try kms which has recently been merged into stable. However I get this when kldload'ing i915kms: drmn0: Intel SandyBridge (M) on vgapci0 info: [drm] MSI enabled 1 message(s) error: [drm:pid1295:drm_load] *ERROR* Card isn't AGP, or couldn't initialize AGP. device_attach: drmn0 attach returned 12 CPU is this model: CPU: Intel(R) Xeon(R) CPU E31260L @ 2.40GHz (2400.07-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Is this model supposed to work with the current code? Show pciconf -lv output. Also show the dmesg from verbose boot. pgp6Fw6vrbXIq.pgp Description: PGP signature
Re: KMS on Sandy bridge error device_attach
On Fri, Jun 22, 2012 at 08:28:29PM +0200, Thomas Zander wrote: Hello Konstantin, Do not strip lists from Cc:, I am not your tech support. On Fri, Jun 22, 2012 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: CPU: Intel(R) Xeon(R) CPU E31260L @ 2.40GHz (2400.07-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Is this model supposed to work with the current code? Show pciconf -lv output. Also show the dmesg from verbose boot. Thank you for your quick response. Output is attached. This is probably one of the relatively rarely sold CPUs, so I might have an edge case here... Yes, indeed, this is something Intel calls 'SandyBridge server Integrated Graphics'. The device id is known to agp driver, but probably it failed to attach due to some (mis)interpretation of the state. Your dmesg is not complete, the hda output displaced the previous messages which contained the agp attach diagnostic. Take agp or hda out from kernel, and rerun the test. Or, increase MSGBUF_SIZE, see conf/NOTES for description. pgpQJrWzvyvO2.pgp Description: PGP signature
Re: svn commit: r237318 - in stable/8: share/man/man4 sys/cam sys/cam/scsi sys/conf
On 6/20/2012 10:39 AM, Alexander Motin wrote: Author: mav Date: Wed Jun 20 14:39:35 2012 New Revision: 237318 URL: http://svn.freebsd.org/changeset/base/237318 Log: MFC r236712: To make CAM debugging easier, compile in some debug flags (CAM_DEBUG_INFO, CAM_DEBUG_CDB, CAM_DEBUG_PERIPH and CAM_DEBUG_PROBE) by default. List of these flags can be modified with CAM_DEBUG_COMPILE kernel option. CAMDEBUG kernel option still enables all possible debug, if not overriden. Additional 50KB of kernel size is a good price for the ability to debug problems without rebuilding the kernel. In case where size is important, debugging can be compiled out by setting CAM_DEBUG_COMPILE option to 0. Hi, Not sure if this is the commit or not, but a kernel from the 18th seems to function normally, and a kernel from today has a great deal of messages like the ones below. I also dont know if this is just exposing an existing bug in the driver that was upto now hidden ? Boot time, I see the following (probe1:twa0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:twa0:0:1:0): CAM status: Invalid Target ID (probe1:twa0:0:1:0): Error 22, Unretryable error (probe2:twa0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe2:twa0:0:2:0): CAM status: Invalid Target ID (probe2:twa0:0:2:0): Error 22, Unretryable error (probe3:twa0:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe3:twa0:0:3:0): CAM status: Invalid Target ID (probe3:twa0:0:3:0): Error 22, Unretryable error (probe4:twa0:0:4:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe4:twa0:0:4:0): CAM status: Invalid Target ID (probe4:twa0:0:4:0): Error 22, Unretryable error (probe15:twa0:0:15:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe15:twa0:0:15:0): CAM status: Invalid Target ID (probe15:twa0:0:15:0): Error 22, Unretryable error (probe16:twa0:0:16:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe16:twa0:0:16:0): CAM status: Invalid Target ID (probe16:twa0:0:16:0): Error 22, Unretryable error (probe17:twa0:0:17:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe17:twa0:0:17:0): CAM status: Invalid Target ID (probe17:twa0:0:17:0): Error 22, Unretryable error (probe18:twa0:0:18:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe18:twa0:0:18:0): CAM status: Invalid Target ID (probe18:twa0:0:18:0): Error 22, Unretryable error (probe19:twa0:0:19:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe19:twa0:0:19:0): CAM status: Invalid Target ID (probe19:twa0:0:19:0): Error 22, Unretryable error (probe20:twa0:0:20:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe20:twa0:0:20:0): CAM status: Invalid Target ID (probe20:twa0:0:20:0): Error 22, Unretryable error (probe21:twa0:0:21:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe21:twa0:0:21:0): CAM status: Invalid Target ID (probe21:twa0:0:21:0): Error 22, Unretryable error (probe22:twa0:0:22:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe22:twa0:0:22:0): CAM status: Invalid Target ID (probe22:twa0:0:22:0): Error 22, Unretryable error (probe23:twa0:0:23:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe23:twa0:0:23:0): CAM status: Invalid Target ID (probe23:twa0:0:23:0): Error 22, Unretryable error (probe24:twa0:0:24:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe24:twa0:0:24:0): CAM status: Invalid Target ID (probe24:twa0:0:24:0): Error 22, Unretryable error (probe25:twa0:0:25:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe25:twa0:0:25:0): CAM status: Invalid Target ID (probe25:twa0:0:25:0): Error 22, Unretryable error (probe26:twa0:0:26:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe26:twa0:0:26:0): CAM status: Invalid Target ID (probe26:twa0:0:26:0): Error 22, Unretryable error (probe5:twa0:0:5:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe5:twa0:0:5:0): CAM status: Invalid Target ID (probe5:twa0:0:5:0): Error 22, Unretryable error (probe6:twa0:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe6:twa0:0:6:0): CAM status: Invalid Target ID (probe6:twa0:0:6:0): Error 22, Unretryable error (probe7:twa0:0:7:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe7:twa0:0:7:0): CAM status: Invalid Target ID (probe7:twa0:0:7:0): Error 22, Unretryable error (probe8:twa0:0:8:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:twa0:0:8:0): CAM status: Invalid Target ID (probe8:twa0:0:8:0): Error 22, Unretryable error (probe9:twa0:0:9:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe9:twa0:0:9:0): CAM status: Invalid Target ID (probe9:twa0:0:9:0): Error 22, Unretryable error (probe10:twa0:0:10:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe10:twa0:0:10:0): CAM status: Invalid Target ID (probe10:twa0:0:10:0): Error 22, Unretryable error (probe11:twa0:0:11:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe11:twa0:0:11:0): CAM status: Invalid Target ID (probe11:twa0:0:11:0): Error 22, Unretryable error (probe12:twa0:0:12:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe12:twa0:0:12:0): CAM status: Invalid Target ID (probe12:twa0:0:12:0): Error 22, Unretryable error (probe13:twa0:0:13:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe13:twa0:0:13:0): CAM status: Invalid Target ID (probe13:twa0:0:13:0): Error 22, Unretryable error (probe14:twa0:0:14:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe14:twa0:0:14:0): CAM status: Invalid Target ID
Re: svn commit: r237318 - in stable/8: share/man/man4 sys/cam sys/cam/scsi sys/conf
On 06/22/12 21:41, Mike Tancsa wrote: On 6/20/2012 10:39 AM, Alexander Motin wrote: Author: mav Date: Wed Jun 20 14:39:35 2012 New Revision: 237318 URL: http://svn.freebsd.org/changeset/base/237318 Log: MFC r236712: To make CAM debugging easier, compile in some debug flags (CAM_DEBUG_INFO, CAM_DEBUG_CDB, CAM_DEBUG_PERIPH and CAM_DEBUG_PROBE) by default. List of these flags can be modified with CAM_DEBUG_COMPILE kernel option. CAMDEBUG kernel option still enables all possible debug, if not overriden. Additional 50KB of kernel size is a good price for the ability to debug problems without rebuilding the kernel. In case where size is important, debugging can be compiled out by setting CAM_DEBUG_COMPILE option to 0. Hi, Not sure if this is the commit or not, but a kernel from the 18th seems to function normally, and a kernel from today has a great deal of messages like the ones below. I also dont know if this is just exposing an existing bug in the driver that was upto now hidden ? That's not. That's a bit later. Boot time, I see the following (probe1:twa0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:twa0:0:1:0): CAM status: Invalid Target ID (probe1:twa0:0:1:0): Error 22, Unretryable error (probe2:twa0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe2:twa0:0:2:0): CAM status: Invalid Target ID (probe2:twa0:0:2:0): Error 22, Unretryable error (probe3:twa0:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe3:twa0:0:3:0): CAM status: Invalid Target ID (probe3:twa0:0:3:0): Error 22, Unretryable error (probe4:twa0:0:4:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe4:twa0:0:4:0): CAM status: Invalid Target ID (probe4:twa0:0:4:0): Error 22, Unretryable error (probe15:twa0:0:15:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe15:twa0:0:15:0): CAM status: Invalid Target ID (probe15:twa0:0:15:0): Error 22, Unretryable error (probe16:twa0:0:16:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe16:twa0:0:16:0): CAM status: Invalid Target ID (probe16:twa0:0:16:0): Error 22, Unretryable error (probe17:twa0:0:17:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe17:twa0:0:17:0): CAM status: Invalid Target ID (probe17:twa0:0:17:0): Error 22, Unretryable error (probe18:twa0:0:18:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe18:twa0:0:18:0): CAM status: Invalid Target ID (probe18:twa0:0:18:0): Error 22, Unretryable error (probe19:twa0:0:19:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe19:twa0:0:19:0): CAM status: Invalid Target ID (probe19:twa0:0:19:0): Error 22, Unretryable error (probe20:twa0:0:20:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe20:twa0:0:20:0): CAM status: Invalid Target ID (probe20:twa0:0:20:0): Error 22, Unretryable error (probe21:twa0:0:21:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe21:twa0:0:21:0): CAM status: Invalid Target ID (probe21:twa0:0:21:0): Error 22, Unretryable error (probe22:twa0:0:22:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe22:twa0:0:22:0): CAM status: Invalid Target ID (probe22:twa0:0:22:0): Error 22, Unretryable error (probe23:twa0:0:23:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe23:twa0:0:23:0): CAM status: Invalid Target ID (probe23:twa0:0:23:0): Error 22, Unretryable error (probe24:twa0:0:24:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe24:twa0:0:24:0): CAM status: Invalid Target ID (probe24:twa0:0:24:0): Error 22, Unretryable error (probe25:twa0:0:25:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe25:twa0:0:25:0): CAM status: Invalid Target ID (probe25:twa0:0:25:0): Error 22, Unretryable error (probe26:twa0:0:26:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe26:twa0:0:26:0): CAM status: Invalid Target ID (probe26:twa0:0:26:0): Error 22, Unretryable error (probe5:twa0:0:5:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe5:twa0:0:5:0): CAM status: Invalid Target ID (probe5:twa0:0:5:0): Error 22, Unretryable error (probe6:twa0:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe6:twa0:0:6:0): CAM status: Invalid Target ID (probe6:twa0:0:6:0): Error 22, Unretryable error (probe7:twa0:0:7:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe7:twa0:0:7:0): CAM status: Invalid Target ID (probe7:twa0:0:7:0): Error 22, Unretryable error (probe8:twa0:0:8:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe8:twa0:0:8:0): CAM status: Invalid Target ID (probe8:twa0:0:8:0): Error 22, Unretryable error (probe9:twa0:0:9:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe9:twa0:0:9:0): CAM status: Invalid Target ID (probe9:twa0:0:9:0): Error 22, Unretryable error (probe10:twa0:0:10:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe10:twa0:0:10:0): CAM status: Invalid Target ID (probe10:twa0:0:10:0): Error 22, Unretryable error (probe11:twa0:0:11:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe11:twa0:0:11:0): CAM status: Invalid Target ID (probe11:twa0:0:11:0): Error 22, Unretryable error (probe12:twa0:0:12:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe12:twa0:0:12:0): CAM status: Invalid Target ID (probe12:twa0:0:12:0): Error 22, Unretryable error (probe13:twa0:0:13:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe13:twa0:0:13:0): CAM status: Invalid Target ID (probe13:twa0:0:13:0): Error 22, Unretryable error (probe14:twa0:0:14:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe14:twa0:0:14:0):
Intel X520-DA2 Supported in stable/8?
Hi All, Wondering if the Intel X520-DA2 10G Fibre NIC is supported in stable/8. Hardware notes don't specify it, but I have a system up and the interfaces appear to be loaded by the ix driver. However, status indicates no carrier. -- Take care Rick Miller ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn commit: r237318 - in stable/8: share/man/man4 sys/cam sys/cam/scsi sys/conf
On Friday, June 22, 2012 2:41:35 pm Mike Tancsa wrote: Using jhb's handy pciconf from HEAD, I see (pciconf -lvcbe) twa0@pci0:2:0:0:class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 vendor = '3ware Inc' device = '9650SE SATA-II RAID PCIe' class = mass storage subclass = RAID bar [10] = type Prefetchable Memory, range 64, base 0x81c00, size 33554432, enabled bar [18] = type Memory, range 64, base 0xe242, size 4096, enabled bar [20] = type I/O Port, range 32, base 0x4000, size 256, enabled cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 32 messages, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(512) link x1(x8) ecap 0001[100] = AER 1 1 fatal 0 non-fatal 0 corrected PCI-e errors = Fatal Error Detected Unsupported Request Detected Fatal = Unsupported Request Looking at the pciconf output from the older kernel, the unsupported request is there too twa0@pci0:2:0:0:class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 vendor = '3ware Inc' device = '9650SE SATA-II RAID PCIe' class = mass storage subclass = RAID bar [10] = type Prefetchable Memory, range 64, base 0x81c00, size 33554432, enabled bar [18] = type Memory, range 64, base 0xe242, size 4096, enabled bar [20] = type I/O Port, range 32, base 0x4000, size 256, enabled cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 32 messages, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(512) link x1(x8) ecap 0001[100] = AER 1 1 fatal 0 non-fatal 0 corrected PCI-e errors = Fatal Error Detected Unsupported Request Detected Fatal = Unsupported Request I think you can ignore these. I think they happen during POST. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn commit: r237318 - in stable/8: share/man/man4 sys/cam sys/cam/scsi sys/conf
On 6/22/2012 3:06 PM, John Baldwin wrote: PCI-e errors = Fatal Error Detected Unsupported Request Detected Fatal = Unsupported Request I think you can ignore these. I think they happen during POST. Thanks! A handy diagnostic tool to have BTW. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
On Fri, Jun 22, 2012 at 3:13 PM, Rick Miller vmil...@hostileadmin.com wrote: Hi All, Wondering if the Intel X520-DA2 10G Fibre NIC is supported in stable/8. Hardware notes don't specify it, but I have a system up and the interfaces appear to be loaded by the ix driver. However, status indicates no carrier. Ok, brain fart. Please forgive my ineptitude. I once sent an email inquiring about the Intel 82599, which is this NIC. Responses to that mail say it's supported by the ixgbe driver. My stable/8 installation (5/21/2012) probes it with an ix driver that I cannot find any info on. The ixgbe manage indicates it only supports 82598 based controllers. Not sure what to think here... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pkgng (Was: Why Are You NOT Using FreeBSD ?)
On Fri, Jun 01, 2012 at 04:09:53PM -0400, Chris Nehren wrote: On Fri, Jun 01, 2012 at 14:50:22 -0500 , Bryan Drewery wrote: FWIW, there is freebsd-update(8) now for binary updating of base, and pkgng[1] will allow binary upgrading of packages/ports similar to apt-get. [1] http://wiki.freebsd.org/pkgng The thing that really has me attracted to pkgng is that it's based on a C library with a public API that developers can use / abuse. It's not (AFAIK) officially released yet, but some early work I've been doing with it has shown it to be useful enough. -- Thanks and best regards, Chris Nehren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Do not hesitate to propose patches or bring feedback on how we can improve the situation with library. The API is public but will only be consider as stable before 2.0, because it can be greatly improved and we hope to have reviews and feedback and cleanup before marking it stable. regards, Bapt pgpaZhs06qJxn.pgp Description: PGP signature
Re: 9-STABLE doesn't build with clang/llvm
On 2012-06-22 13:47, Dr. Baud wrote: Anybody else having trouble building r237440 with clang: ... /usr/home/bketchum/kernels/stable-9/lib/libc/../../include/stdlib.h:82:1: error: unknown type name '_Noreturn' _Noreturn void abort(void); ^ There seems to be something wrong with your cdefs.h file. Please check your copy, which should be in: /usr/home/bketchum/kernels/stable-9/sys/sys/cdefs.h Alternatively, try running the failing command line with -save-temps, and upload the resulting bt_close.i somewhere (or attach it, but compress it first, please). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
The ixgbe driver creates devices named ix0, etc. I believe you need to run 'ifconfig ix0 up' before it will attempt to get link. -Andrew On Jun 22, 2012, at 3:45 PM, Rick Miller wrote: On Fri, Jun 22, 2012 at 3:13 PM, Rick Miller vmil...@hostileadmin.com wrote: Hi All, Wondering if the Intel X520-DA2 10G Fibre NIC is supported in stable/8. Hardware notes don't specify it, but I have a system up and the interfaces appear to be loaded by the ix driver. However, status indicates no carrier. Ok, brain fart. Please forgive my ineptitude. I once sent an email inquiring about the Intel 82599, which is this NIC. Responses to that mail say it's supported by the ixgbe driver. My stable/8 installation (5/21/2012) probes it with an ix driver that I cannot find any info on. The ixgbe manage indicates it only supports 82598 based controllers. Not sure what to think here... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Andrew Boyerabo...@averesystems.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
On Fri, Jun 22, 2012 at 3:54 PM, Andrew Boyer abo...@averesystems.com wrote: The ixgbe driver creates devices named ix0, etc. I believe you need to run 'ifconfig ix0 up' before it will attempt to get link. Thanks for clarifying that tidbit. At least I know the driver loading is the correct driver :) I did try ifup'ing the interface...it shows the interface up, status is still no carrier. I've had confirmation that the cable itself is good. I wonder if it matters that the upstream switch has VLAN tagging enabled? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [wifi] wifimgr for freebsd
Hi! On 18 June 2012 03:43, freegih free...@gmail.com wrote: Hi, I made a wifi script based on the wlanconfig in bsdinstaller. here is the code: https://github.com/gihnius/freebsd-wifi I think we can make it more suitable for many devices and normal use. Any idea to write a normal feature script to use freebsd wifi easily ? and thanks to the author of wlanconfig. I'd love to see a non-ridiculous command line toolkit (which could later be extended to be GUI) for FreeBSD wireless. I suggest canvasing the freebsd forums and speak to whoever pipes up with some ideas. That crowd is very likely the right target for this kind of work. :) Good luck! adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [wifi] wifimgr for freebsd
On Jun 22, 2012, at 1:32 PM, Adrian Chadd wrote: Hi! On 18 June 2012 03:43, freegih free...@gmail.com wrote: Hi, I made a wifi script based on the wlanconfig in bsdinstaller. here is the code: https://github.com/gihnius/freebsd-wifi I think we can make it more suitable for many devices and normal use. Any idea to write a normal feature script to use freebsd wifi easily ? and thanks to the author of wlanconfig. I'd love to see a non-ridiculous command line toolkit (which could later be extended to be GUI) for FreeBSD wireless. I think bsdconfig is the right landing zone for this (once it's tested -- check out the port sysutils/bsdconfig -- and committed). bsdconfig is: (a) scriptable (b) pluggable (c) modular (d) Supports both Command-line (dialog) and GUI (Xdialog) (e) is i18n-compatible (f) written in sh(1) with very clean code that is properly scoped and consistent -- Devin I suggest canvasing the freebsd forums and speak to whoever pipes up with some ideas. That crowd is very likely the right target for this kind of work. :) Good luck! adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
On 22 Jun 2012, at 22:02, Rick Miller vmil...@hostileadmin.com wrote: On Fri, Jun 22, 2012 at 3:54 PM, Andrew Boyer abo...@averesystems.com wrote: The ixgbe driver creates devices named ix0, etc. I believe you need to run 'ifconfig ix0 up' before it will attempt to get link. Thanks for clarifying that tidbit. At least I know the driver loading is the correct driver :) I did try ifup'ing the interface...it shows the interface up, status is still no carrier. I've had confirmation that the cable itself is good. I wonder if it matters that the upstream switch has VLAN tagging enabled? Nope, having a link is layer 1, VLAN tagging happens at layer 3 iirc. If you're unsure, you can always create a VLAN interface bound to your NIC. I suppose you've tried reversing the fibre pair.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
dmesg and ifconfig output below... On Fri, Jun 22, 2012 at 4:02 PM, Rick Miller vmil...@hostileadmin.com wrote: On Fri, Jun 22, 2012 at 3:54 PM, Andrew Boyer abo...@averesystems.com wrote: The ixgbe driver creates devices named ix0, etc. I believe you need to run 'ifconfig ix0 up' before it will attempt to get link. Thanks for clarifying that tidbit. At least I know the driver loading is the correct driver :) I did try ifup'ing the interface...it shows the interface up, status is still no carrier. I've had confirmation that the cable itself is good. I wonder if it matters that the upstream switch has VLAN tagging enabled? ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x7000-0x701f mem 0xf6b8-0xf6bf,0xf6b7-0xf6b73fff irq 40 at device 0.0 on pci7 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 90:e2:ba:15:e2:60 ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ix1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x7020-0x703f mem 0xf6a8-0xf6af,0xf6a7-0xf6a73fff irq 44 at device 0.1 on pci7 ix1: Using MSIX interrupts with 9 vectors ix1: RX Descriptors exceed system mbuf max, using default instead! ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: Ethernet address: 90:e2:ba:15:e2:61 ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 ix0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether 90:e2:ba:XX:XX:XX inet 10.1.2.50 netmask 0xfe00 broadcast 10.1.3.255 media: Ethernet autoselect status: no carrier ix1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether 90:e2:ba:XX:XX:XX media: Ethernet autoselect status: no carrier -- Take care Rick Miller ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
Increase your system mbuf pool size, you do not want that failure to happen. Jack On Fri, Jun 22, 2012 at 2:01 PM, Rick Miller vmil...@hostileadmin.comwrote: dmesg and ifconfig output below... On Fri, Jun 22, 2012 at 4:02 PM, Rick Miller vmil...@hostileadmin.com wrote: On Fri, Jun 22, 2012 at 3:54 PM, Andrew Boyer abo...@averesystems.com wrote: The ixgbe driver creates devices named ix0, etc. I believe you need to run 'ifconfig ix0 up' before it will attempt to get link. Thanks for clarifying that tidbit. At least I know the driver loading is the correct driver :) I did try ifup'ing the interface...it shows the interface up, status is still no carrier. I've had confirmation that the cable itself is good. I wonder if it matters that the upstream switch has VLAN tagging enabled? ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x7000-0x701f mem 0xf6b8-0xf6bf,0xf6b7-0xf6b73fff irq 40 at device 0.0 on pci7 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 90:e2:ba:15:e2:60 ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ix1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x7020-0x703f mem 0xf6a8-0xf6af,0xf6a7-0xf6a73fff irq 44 at device 0.1 on pci7 ix1: Using MSIX interrupts with 9 vectors ix1: RX Descriptors exceed system mbuf max, using default instead! ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: Ethernet address: 90:e2:ba:15:e2:61 ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 ix0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether 90:e2:ba:XX:XX:XX inet 10.1.2.50 netmask 0xfe00 broadcast 10.1.3.255 media: Ethernet autoselect status: no carrier ix1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether 90:e2:ba:XX:XX:XX media: Ethernet autoselect status: no carrier -- Take care Rick Miller ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
fsck_ufs running too often
Hi, since a few of days ago, I noticed my home server turns very slow more than once a day, so every time I run top to see what's processes are running, I can see fsck_ufs at the very top, and the hard drive working like mad. I've checked my crontab and there's nothing related to fsck_ufs, where can I start searching for the cause of the problem?, I thought this process should run only at boot or shutdown, but this time it is running -apparently- without a cause. uname -a: FreeBSD server.my.local 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Regards, Leonardo M. Ramé http://leonardorame.blogspot.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fsck_ufs running too often
On Jun 22, 2012, at 5:47 PM, Leonardo M. Ramé martinr...@yahoo.com wrote: Hi, since a few of days ago, I noticed my home server turns very slow more than once a day, so every time I run top to see what's processes are running, I can see fsck_ufs at the very top, and the hard drive working like mad. I've checked my crontab and there's nothing related to fsck_ufs, where can I start searching for the cause of the problem?, I thought this process should run only at boot or shutdown, but this time it is running -apparently- without a cause. uname -a: FreeBSD server.my.local 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Regards, Leonardo M. Ramé http://leonardorame.blogspot.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Can you tell us more about your server . Does its crash or reboot unexpectedly ? Is this an ungraded server , was it FreeBSD 6,7, or 8 prior ? Also do you have any ufs1 file systems mounted? Please send the output from mount -t ufs and your dmesg . --- Mark saad | mark.saad@longcount.org___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
On Fri, Jun 22, 2012 at 5:21 PM, Jack Vogel jfvo...@gmail.com wrote: Increase your system mbuf pool size, you do not want that failure to happen. Thanks, Jack. I saw a thread where you discussed this. You are referring to kern.ipc.nmbclusters, correct? Should I also adjust the following? hw.ixgbe.rxd hw.ixgbe.txd hw.ixgbe.num_queues hw.intr_storm_threshold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. This was on-purpose because there is a discrepancy in passwd(5) manual regarding what a value of zero (0) means for these fields. From passwd(5): The change field is the number of seconds from the epoch, UTC, until the password for the account must be changed. This field may be left empty to turn off the password aging feature. Nowhere in the manual does it say that zero is a synonym to being left empty. So I can think of one of two solutions: Update the manual to say that 0 is the same as being left empty or Change the behavior to treat zero as [zero] seconds from the epoch. Currently, bsdconfig treats zero as the latter, not the former -- until such discrepancy can be resolved. NOTE: It should also be noted that Linux and FreeBSD when pointed at the same LDAP server have disagreements between the value of this field and the best solution in this situation is to remove the field in question (e.g., shadowExpire, shadowMax, etc.). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 3:32 PM, Devin Teske wrote: On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. This was on-purpose because there is a discrepancy in passwd(5) manual regarding what a value of zero (0) means for these fields. From passwd(5): The change field is the number of seconds from the epoch, UTC, until the password for the account must be changed. This field may be left empty to turn off the password aging feature. Nowhere in the manual does it say that zero is a synonym to being left empty. And yet, this is how the system treats zero (was my complaint). The user root (and toor, and several other system users) come with a default value of zero for this field. If zero was treated according to the manual, then root would be disabled by default. But that's clearly not the case in a default installation which has a value of zero. So, when you're using bsdconfig to view an existing user that has a value of zero, you will notice that the default calendar date/time that is chosen corresponds to zero seconds from the epoch, UTC, despite the fact that I know (and you know) that zero is synonymous with NULL. So I'm a fan of updating the man page and when that is done, I am happy to change bsdconfig to treat zero as-such. But right now I wanted to stay true to the manual (which plainly states that any non-NULL value is treated as seconds from the epoch). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
Would probably be good to take care of the storm threshold if you haven't, set it to 0 and you disable the check, that's what we do internally. As for the queues and number of descriptors, that's kind of up to you, different work loads and environments work best with different setups. Hopefully, when you get rid of the rx ring setup failure you will get things working. Jack On Fri, Jun 22, 2012 at 3:19 PM, Rick Miller vmil...@hostileadmin.comwrote: On Fri, Jun 22, 2012 at 5:21 PM, Jack Vogel jfvo...@gmail.com wrote: Increase your system mbuf pool size, you do not want that failure to happen. Thanks, Jack. I saw a thread where you discussed this. You are referring to kern.ipc.nmbclusters, correct? Should I also adjust the following? hw.ixgbe.rxd hw.ixgbe.txd hw.ixgbe.num_queues hw.intr_storm_threshold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic at early boot time
Thanks for explaining the cause! On Tue, Jun 19, 2012 at 4:54 AM, John Baldwin j...@freebsd.org wrote: On Sunday, June 17, 2012 2:35:14 pm mnln.l4 wrote: I get a kernel panic at early boot time on 9.0-stable (r237150), GENERIC, AMD64. Repro step: 1. Boot, wait for welcome screen. 2. Repeat pressing Enter key rapidly (so kernel is loading, don't stop pressing Enter key). 3. See the following message at early boot So don't do that. All your key presses are triggering SMI# events that are interfering with the AP's ability to respond to its startup IPI. There is nothing we can do about this in the OS. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
