Re: [RFQ] make witness panic an option
On 11/15/12 11:22 PM, Andriy Gapon wrote: on 16/11/2012 01:20 Alfred Perlstein said the following: We need to enable developers to skip these areas and test their own code. I wish that there was a magic knob to ignore build breakages, so that the developers could test how their own code compiles :-) There is, it's called updating to known good tinderbox build and basing changes off of that. On a serious note, why stop here? E.g. Solaris seems to have knob to ignore all asserts (just to print a message, but not panic). There is no reason why not to add such a thing, in fact it would be really handy for some of our users who need asserts, but sometimes can't clean up the entire code base. Adding another option to tag asserts so that it was sort of like: KASSERT((cond, section, "string")); would be interesting, then you could turn KASSERTS on based on "vfs" or possibly file by file. -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Build and Release automation with Perl.
Dear All, I am keen to know if you have any guideline for Build and Release Automation with Perl Language. I am interested to drill down further to explore this field. Kindly advised. Thanks. Regards, MT TAJUDIN ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: stop_cpus_hard when multiple CPUs are panicking from an NMI
On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote: > on 16/11/2012 00:58 Ryan Stone said the following: >> At work we have some custom watchdog hardware that sends an NMI upon >> expiry. We've modified the kernel to panic when it receives the watchdog >> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >> discovered that when my watchdog expires, the system gets completely >> wedged. After some digging, I've discovered is that I have multiple CPUs >> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >> wins, and the rest spin forever in this code: >> >> /* >> * We don't want multiple CPU's to panic at the same time, so we >> * use panic_cpu as a simple spinlock. We have to keep checking >> * panic_cpu if we are spinning in case the panic on the first >> * CPU is canceled. >> */ >> if (panic_cpu != PCPU_GET(cpuid)) >> while (atomic_cmpset_int(&panic_cpu, NOCPU, >> PCPU_GET(cpuid)) == 0) >> while (panic_cpu != NOCPU) >> ; /* nothing */ >> >> The system wedges when stop_cpus_hard() is called, which sends NMIs to all >> of the other CPUs and waits for them to acknowledge that they are stopped >> before returning. However the CPU will not deliver an NMI to a CPU that is >> already handling an NMI, so the other CPUs that got a watchdog NMI and are >> spinning will never go into the NMI handler and acknowledge that they are >> stopped. > > I thought about this issue and fixed (in my tree) in a different way: > http://people.freebsd.org/~avg/cpu_stop-race.diff > > The need for spinlock_enter in the patch in not entirely clear. > The main idea is that a CPU which calls cpu_stop and loses a race should > voluntary enter cpustop_handler. > I am also not sure about MI-cleanness of this patch. It is similar to what I propose but with some differences: - It is not clean from MI perspective - I don't think we need to treact it specially, I would just unconditionally stop all the CPUs entering in the "spinlock zone", making the patch simpler. So I guess you are really fine with the proposal I made? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFQ] make witness panic an option
On Fri, Nov 16, 2012 at 7:19 AM, Andriy Gapon wrote: > on 16/11/2012 01:38 Attilio Rao said the following: >> On Thu, Nov 15, 2012 at 8:51 PM, Andriy Gapon wrote: >>> on 15/11/2012 22:00 Adrian Chadd said the following: But I think my change is invaluable for development, where you want to improve and debug the locking and lock interactions of a subsystem. >>> >>> My practical experience was that if you mess up one lock in one place, then >>> it >>> is a total mess further on. but apparently you've got a different practical >>> experience :) >>> What would indeed be invaluable to _me_ - if the LOR messages also produced >>> the >>> stack(s) where a supposedly correct lock order was learned. >> >> Please note that the "supposedly correct lock order", as for the >> definition that it is correct, can be used in several different >> stacks. I don't see the point of saving it somewhere. >> The only helpful case would be if the "wrong order" is catched first. >> If this is really the case, I suggest you to force the order you >> expect in the static table so that the first time the wrong order >> happens it yells. > > Exactly my point - if I am a user of some code, not its developer, and I don't > know which one is the correct order I would have had the complete information > from the very start instead of having to jump through the hoops. I don't agree -- such informations are only useful to developers and also what should we do, store all the valid stacktraces? I don't understand what are you expecting here honestly. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: stop_cpus_hard when multiple CPUs are panicking from an NMI
on 16/11/2012 14:30 Attilio Rao said the following: > On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote: >> on 16/11/2012 00:58 Ryan Stone said the following: >>> At work we have some custom watchdog hardware that sends an NMI upon >>> expiry. We've modified the kernel to panic when it receives the watchdog >>> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >>> discovered that when my watchdog expires, the system gets completely >>> wedged. After some digging, I've discovered is that I have multiple CPUs >>> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >>> wins, and the rest spin forever in this code: >>> >>> /* >>> * We don't want multiple CPU's to panic at the same time, so we >>> * use panic_cpu as a simple spinlock. We have to keep checking >>> * panic_cpu if we are spinning in case the panic on the first >>> * CPU is canceled. >>> */ >>> if (panic_cpu != PCPU_GET(cpuid)) >>> while (atomic_cmpset_int(&panic_cpu, NOCPU, >>> PCPU_GET(cpuid)) == 0) >>> while (panic_cpu != NOCPU) >>> ; /* nothing */ >>> >>> The system wedges when stop_cpus_hard() is called, which sends NMIs to all >>> of the other CPUs and waits for them to acknowledge that they are stopped >>> before returning. However the CPU will not deliver an NMI to a CPU that is >>> already handling an NMI, so the other CPUs that got a watchdog NMI and are >>> spinning will never go into the NMI handler and acknowledge that they are >>> stopped. >> >> I thought about this issue and fixed (in my tree) in a different way: >> http://people.freebsd.org/~avg/cpu_stop-race.diff >> >> The need for spinlock_enter in the patch in not entirely clear. >> The main idea is that a CPU which calls cpu_stop and loses a race should >> voluntary enter cpustop_handler. >> I am also not sure about MI-cleanness of this patch. > > It is similar to what I propose but with some differences: > - It is not clean from MI perspective OK. > - I don't think we need to treact it specially, I would just > unconditionally stop all the CPUs entering in the "spinlock zone", > making the patch simpler. I couldn't understand this part. > So I guess you are really fine with the proposal I made? I definitely agree with with the MI cpustop_handler part. I couldn't understand the rest of the proposal. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: stop_cpus_hard when multiple CPUs are panicking from an NMI
On Fri, Nov 16, 2012 at 1:18 PM, Andriy Gapon wrote:
> on 16/11/2012 14:30 Attilio Rao said the following:
>> On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote:
>>> on 16/11/2012 00:58 Ryan Stone said the following:
At work we have some custom watchdog hardware that sends an NMI upon
expiry. We've modified the kernel to panic when it receives the watchdog
NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've
discovered that when my watchdog expires, the system gets completely
wedged. After some digging, I've discovered is that I have multiple CPUs
getting the watchdog NMI and trying to panic concurrently. One of the CPUs
wins, and the rest spin forever in this code:
/*
* We don't want multiple CPU's to panic at the same time, so we
* use panic_cpu as a simple spinlock. We have to keep checking
* panic_cpu if we are spinning in case the panic on the first
* CPU is canceled.
*/
if (panic_cpu != PCPU_GET(cpuid))
while (atomic_cmpset_int(&panic_cpu, NOCPU,
PCPU_GET(cpuid)) == 0)
while (panic_cpu != NOCPU)
; /* nothing */
The system wedges when stop_cpus_hard() is called, which sends NMIs to all
of the other CPUs and waits for them to acknowledge that they are stopped
before returning. However the CPU will not deliver an NMI to a CPU that is
already handling an NMI, so the other CPUs that got a watchdog NMI and are
spinning will never go into the NMI handler and acknowledge that they are
stopped.
>>>
>>> I thought about this issue and fixed (in my tree) in a different way:
>>> http://people.freebsd.org/~avg/cpu_stop-race.diff
>>>
>>> The need for spinlock_enter in the patch in not entirely clear.
>>> The main idea is that a CPU which calls cpu_stop and loses a race should
>>> voluntary enter cpustop_handler.
>>> I am also not sure about MI-cleanness of this patch.
>>
>> It is similar to what I propose but with some differences:
>> - It is not clean from MI perspective
>
> OK.
>
>> - I don't think we need to treact it specially, I would just
>> unconditionally stop all the CPUs entering in the "spinlock zone",
>> making the patch simpler.
>
> I couldn't understand this part.
I'm sorry, I think I misread your patch.
I was basically suggesting to fix Ryan case by calling
cpustop_handler() (or the new MI interface) into the panic() function,
in the case the CPU don't win the race for panic_cpu.
Basically doing:
Index: sys/kern/kern_shutdown.c
===
--- sys/kern/kern_shutdown.c(revision 243154)
+++ sys/kern/kern_shutdown.c(working copy)
@@ -568,15 +568,11 @@ panic(const char *fmt, ...)
#ifdef SMP
/*
* We don't want multiple CPU's to panic at the same time, so we
-* use panic_cpu as a simple spinlock. We have to keep checking
-* panic_cpu if we are spinning in case the panic on the first
-* CPU is canceled.
+* use panic_cpu as a simple lock.
*/
if (panic_cpu != PCPU_GET(cpuid))
- while (atomic_cmpset_int(&panic_cpu, NOCPU,
- PCPU_GET(cpuid)) == 0)
- while (panic_cpu != NOCPU)
- ; /* nothing */
+ if (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) == 0)
+ cpustop_handler();
if (stop_scheduler_on_panic) {
if (panicstr == NULL && !kdb_active) {
Infact it seems to me that the comment is outdated and no longer
represent truth.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: stop_cpus_hard when multiple CPUs are panicking from an NMI
on 16/11/2012 16:41 Attilio Rao said the following:
> On Fri, Nov 16, 2012 at 1:18 PM, Andriy Gapon wrote:
>> on 16/11/2012 14:30 Attilio Rao said the following:
>>> On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote:
on 16/11/2012 00:58 Ryan Stone said the following:
> At work we have some custom watchdog hardware that sends an NMI upon
> expiry. We've modified the kernel to panic when it receives the watchdog
> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've
> discovered that when my watchdog expires, the system gets completely
> wedged. After some digging, I've discovered is that I have multiple CPUs
> getting the watchdog NMI and trying to panic concurrently. One of the
> CPUs
> wins, and the rest spin forever in this code:
>
> /*
> * We don't want multiple CPU's to panic at the same time, so we
> * use panic_cpu as a simple spinlock. We have to keep checking
> * panic_cpu if we are spinning in case the panic on the first
> * CPU is canceled.
> */
> if (panic_cpu != PCPU_GET(cpuid))
> while (atomic_cmpset_int(&panic_cpu, NOCPU,
> PCPU_GET(cpuid)) == 0)
> while (panic_cpu != NOCPU)
> ; /* nothing */
>
> The system wedges when stop_cpus_hard() is called, which sends NMIs to all
> of the other CPUs and waits for them to acknowledge that they are stopped
> before returning. However the CPU will not deliver an NMI to a CPU that
> is
> already handling an NMI, so the other CPUs that got a watchdog NMI and are
> spinning will never go into the NMI handler and acknowledge that they are
> stopped.
I thought about this issue and fixed (in my tree) in a different way:
http://people.freebsd.org/~avg/cpu_stop-race.diff
The need for spinlock_enter in the patch in not entirely clear.
The main idea is that a CPU which calls cpu_stop and loses a race should
voluntary enter cpustop_handler.
I am also not sure about MI-cleanness of this patch.
>>>
>>> It is similar to what I propose but with some differences:
>>> - It is not clean from MI perspective
>>
>> OK.
>>
>>> - I don't think we need to treact it specially, I would just
>>> unconditionally stop all the CPUs entering in the "spinlock zone",
>>> making the patch simpler.
>>
>> I couldn't understand this part.
>
> I'm sorry, I think I misread your patch.
>
> I was basically suggesting to fix Ryan case by calling
> cpustop_handler() (or the new MI interface) into the panic() function,
> in the case the CPU don't win the race for panic_cpu.
> Basically doing:
> Index: sys/kern/kern_shutdown.c
> ===
> --- sys/kern/kern_shutdown.c(revision 243154)
> +++ sys/kern/kern_shutdown.c(working copy)
> @@ -568,15 +568,11 @@ panic(const char *fmt, ...)
> #ifdef SMP
> /*
> * We don't want multiple CPU's to panic at the same time, so we
> -* use panic_cpu as a simple spinlock. We have to keep checking
> -* panic_cpu if we are spinning in case the panic on the first
> -* CPU is canceled.
> +* use panic_cpu as a simple lock.
> */
> if (panic_cpu != PCPU_GET(cpuid))
> - while (atomic_cmpset_int(&panic_cpu, NOCPU,
> - PCPU_GET(cpuid)) == 0)
> - while (panic_cpu != NOCPU)
> - ; /* nothing */
> + if (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) ==
> 0)
> + cpustop_handler();
>
> if (stop_scheduler_on_panic) {
> if (panicstr == NULL && !kdb_active) {
>
>
> Infact it seems to me that the comment is outdated and no longer
> represent truth.
Ah, I see. Thank you.
My older plan was to get rid of stop_scheduler_on_panic, that is to make the
behavior unconditional. And then to use stop_cpus_hard instead of the
hand-rolled
'panic_cpu' spinlock. This way the whichever CPU wins stop_cpus_hard would be
the
only CPU to enter panic.
Sorry, if I was not fully clear when I posted my patch.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page
on 15/11/2012 23:44 Attilio Rao said the following: > Do you think you can test this patch?: > http://www.freebsd.org/~attilio/lockmgr_forcerec.patch I will use this patch in my tree, but I think that it is effectively already quite well tested by using INVARIANTS+WITNESS. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Using PC-Sysinstall for automated network installs of FreeBSD
All
I wanted to share with you my method for network installs of FreeBSD
9.1-RCn . This does not use PC-BSD just stock FreeBSD. This should
work on 9.0-RELEASE is known to work on 9.1-RC's and BETA.
I decided to use pc-sysinstall in place of bsdinstall as pc-sysinstall
supported using a config file that could be passed to the installer
much like the old sysinstall way of doing things.
Jumpstart host:
--
Exported filesystems: /export/
Useful paths on /export, /export/install/freebsd/9.1/{i386,amd64}
this is the contents of the install media rsync'd to a local filesystem
TFTP configured to server from /tftpboot which is a symlink to
/export/install/freebsd/9.1/{i386,amd64}
DHCPD configured as follows
subnet 10.1.5.0 netmask 255.255.255.0 {
authoritative;
option netbios-name-servers 10.1.5.252;
option routers 10.1.5.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.1.5.255;
option domain-name "ops.com";
option domain-name-servers 8.8.8.8, 10.1.5.101;
next-server 10.1.5.28;
option root-path "/tftpboot";
filename "/pxeboot";
default-lease-time 21600;
max-lease-time 43200;
}
Changes to make the install media boot the way I want it.
--
1. I copied boot/pxeboot to /export/install/freebsd/9.1/{i386,amd64}
thats a work symantic not required
2. I created a conf directory to store my pc-sysinatll configs
3. I added the following bits to rc.conf to make the nfs root happy
sendmail_enable="NONE"
hostid_enable="NO"
update_motd="NO"
hostid_enable="NO"
varmfs="YES"
hostname="jumpstart00.ops.com"
4. I modified the fstab file as follows
#/dev/iso9660/FREEBSD_INSTALL / cd9660 ro 0 0
none /tmp tmpfs rw 0 0
5 I changed my rc.conf to start a simple shell script and not the
bsdinstall bits
export TERM=vt220
echo "o PC-SYSINSTALL "
exec /conf/picker.sh
6. Here is /conf/picker.sh
#!/bin/sh
: ${DIALOG_OK=0}
: ${DIALOG_CANCEL=1}
: ${DIALOG_HELP=2}
: ${DIALOG_EXTRA=3}
: ${DIALOG_ITEM_HELP=4}
: ${DIALOG_ESC=255}
dialog --backtitle "FreeBSD Jumpstart" --title "Welcome" --no-label
"Shell" --yes-label "Install" --yesno "Welcome to FreeBSD! Woul
d you like to begin an installation or use the live filesystem?" 0 0
case $? in
$DIALOG_OK) # Install
exec /conf/disk.sh
;;
$DIALOG_CANCEL) # Live CD
;;
esac
7. Here is /conf/disk.sh
#!/bin/sh
: ${DIALOG_OK=0}
: ${DIALOG_CANCEL=1}
: ${DIALOG_HELP=2}
: ${DIALOG_EXTRA=3}
: ${DIALOG_ITEM_HELP=4}
: ${DIALOG_ESC=255}
dialog --backtitle "FreeBSD Jumpstart" --title "Select disk type"
--no-label "SCSI/SAS da0" --yes-label "IDE/SATA ada0" --yesno "Se
lect Your servers root disk type" 0 0
case $? in
$DIALOG_OK) # Install IDE/SATA
exec /usr/sbin/pc-sysinstall -c /conf/ada-install.cfg
;;
$DIALOG_CANCEL) # Install SCSI/SAS
exec /usr/sbin/pc-sysinstall -c /conf/da-install.cfg
;;
esac
exit 255
The install config
I created /conf/ada-install.cfg and /conf/da-install.cfg the only
difference here is the name of the disk as that is not auto
discovered.
Here is ada-install.cfg
# User Generated pc-sysinstall configuration
installInteractive=no
installMode=fresh
installType=FreeBSD
installMedium=local
localPath=/usr/freebsd-dist/
installFile=fbsd-release.txz
packageType=tar
hostname=nynewserver1.ops.com
netDev=AUTO-DHCP
# Disk Setup
disk0=ada0 #Change me to suite your needs
partition=ALL
bootManager=bsd
partscheme=GPT
commitDiskPart
# Partition Setup for da0(ALL)
# All sizes are expressed in MB
# Avail FS Types, UFS, UFS+S, UFS+SUJ, UFS+J, ZFS, SWAP
# UFS.eli, UFS+S.eli, UFS+SUJ, UFS+J.eli, ZFS.eli, SWAP.eli
disk0-part=UFS+SUJ 0 /
disk0-part=SWAP 4096 none
disk0-part=UFS+SUJ 10240 /var
commitDiskLabel
# Optional Components
#installComponents=src
# Root Password
rootPass=iAmAwinner
# Setup basic network
runCommand=echo 'ifconfig_bge0="DHCP"' >>/etc/rc.conf
runCommand=echo 'ifconfig_em0="DHCP"' >>/etc/rc.conf
runCommand=echo 'ifconfig_igb0="DHCP"' >>/etc/rc.conf
runCommand=echo 'ifconfig_bce0="DHCP"' >>/etc/rc.conf
runCommand=echo 'ifconfig_nfe0="DHCP"' >>/etc/rc.conf
runCommand=echo 'sshd_enable="YES"' >>/etc/rc.conf
runCommand=echo 'ntpd_enable="YES"' >>/etc/rc.conf
#Tweak the configs
runExtCommand=/mnt/sbin/mount_nullfs /packages/ /mnt/mnt/
runExtCommand=mount -t devfs devfs ${FSMNT}/dev
runCommand=echo "-D" > /boot.config
runCommand=echo 'boot_multicons="YES"' > /boot/loader.conf
runCommand=echo 'boot_serial="YES"' >> /boot/loader.conf
runCommand=echo 'comconsole_speed="9600"' >> /boot/loader.conf
runCommand=echo 'console="comconsole,vidconsole"' >> /boot/loader.conf
runCommand=cp /mnt/sysctl.conf /etc
runCommand=cp /mnt/motd /etc
runCommand=cp /mnt/ttys /etc
runCommand=cp /mnt/sshd_config /etc/ssh/
runCommand=mkdir -p /root/.ssh/
runCommand=chmod 700 /root/.ssh/
runCommand=cp /mnt
Re: [RFQ] make witness panic an option
On 16 November 2012 00:26, Alfred Perlstein wrote: > Adding another option to tag asserts so that it was sort of like: > > KASSERT((cond, section, "string")); would be interesting, then you could > turn KASSERTS on based on "vfs" or possibly file by file. That's orthogonal to my developer-focused request. I'm also a big fan of correctly using asserts/panics - ie, asserts shouldn't replace correct error handling. (Yes, I'm guilty of this in ath(4), but I have plans soon to rectify this.) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFQ] make witness panic an option
On 11/16/12 10:18 AM, Adrian Chadd wrote: On 16 November 2012 00:26, Alfred Perlstein wrote: Adding another option to tag asserts so that it was sort of like: KASSERT((cond, section, "string")); would be interesting, then you could turn KASSERTS on based on "vfs" or possibly file by file. That's orthogonal to my developer-focused request. I'm also a big fan of correctly using asserts/panics - ie, asserts shouldn't replace correct error handling. (Yes, I'm guilty of this in ath(4), but I have plans soon to rectify this.) Adrian I apologize if you took a wishlist item for me as a request for you to take on/augment your patch. It was not my intention. Back to your work, I like your patch quite a bit, I am wondering though if it can be worked into something under witness_kdb though. -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Equivalent of linux F_SETLEASE/F_GETLEASE
Is there a equivalent of Linux "Leases" functionality in FreeBSD ? If not, are there any plans of adding it in the future release? Thanks, Sushanth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
clang mangling some static struct names?
On a very recent clang-built HEAD, I see that some static structures have a ".n" appended to their name. For example, this declaration in the cxgbe driver now results in a t4_list.0 symbol in the KLD: static SLIST_HEAD(, adapter) t4_list; # nm if_cxgbe.ko | grep t4_list 0020 b t4_list.0 gcc used to leave it as t4_list. One problem is that kgdb can't display such an item (it interprets the dot as a delimiter between a structure and its element). Some of the structures listed at the end look strange for other reasons too -- for example, why should there be multiple scsi_low_statics.n symbols when there's only one such structure in scsi_low.c? Regards, Navdeep full list of affected structures (and some false positives?): # nm kernel *.ko | grep '\.[0-9]$' 814802d0 b accept_filtlsthd.0 8125ca88 b acpi_intr_list.0 81292278 b cdevsw_gt_post_list.0 812defc8 b clock_adj.0 812defd0 b clock_adj.1 814d7ac0 b enumerators.0 81292460 b eventtimers.0 81279680 b feedertab.0 81248470 d intr_cpus.0.0 814a0378 b keyboard_drivers.0 81481c60 b lltables.0 814a17a8 b profperiod.1 81482280 b route_cb.0 81482284 b route_cb.1 81482288 b route_cb.2 8148228c b route_cb.3 812796d0 b sndstat_devlist.0 814a17a0 b statperiod.1 812925a4 b tstate.0 812925a8 b tstate.1 8128ab30 b twe_check_bits.lastwarn.0 8128ab38 b twe_check_bits.lastwarn.1 814804d8 b unp_defers.0 81488760 b vm_phys_lookup_lists.0 813e7900 b w_hash.0 813e80dc b w_hash.2 813e58f0 b w_lohash.0 813e78dc b w_lohash.2 0318 d proto_reg.0 031c d proto_reg.1 00c0 b fasttrap_procs.0 00c8 b fasttrap_procs.1 00d0 b fasttrap_procs.2 0080 b fasttrap_provs.0 0088 b fasttrap_provs.1 0090 b fasttrap_provs.2 0028 b t3_list.0 0050 b t3_uld_list.0 0020 b t4_list.0 0048 b t4_uld_list.0 b efdev.0 0190 b Counter.0 0194 b Counter.1 0198 b Counter.2 019c b Counter.3 0028 b taphead.0 1190 b svc_rpc_gss_callbacks.0 1198 b svc_rpc_gss_svc_names.0 0038 b scsi_low_statics.0 003c b scsi_low_statics.1 0040 b scsi_low_statics.2 0044 b scsi_low_statics.3 0048 b scsi_low_statics.4 0008 b feedertab.0 0098 b sndstat_devlist.0 0008 b pcx_info.0 000c b pcx_info.1 0010 b pcx_info.2 0014 b pcx_info.3 0018 b pcx_info.4 001c b pcx_info.5 0020 b pcx_info.6 0028 b pcx_info.7 b twe_check_bits.lastwarn.0 0008 b twe_check_bits.lastwarn.1 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: clang mangling some static struct names?
Yes, it does that. iirc so that you can have things like
void foo(int cond) {
if (cond) {
static int i = 7;
} else {
static int i = 8;
}
}
working correctly.
I dont know why scsi_low_statics is there multiple times.
On Fri, Nov 16, 2012 at 12:36:13PM -0800, Navdeep Parhar wrote:
> On a very recent clang-built HEAD, I see that some static structures
> have a ".n" appended to their name. For example, this declaration in
> the cxgbe driver now results in a t4_list.0 symbol in the KLD:
>
> static SLIST_HEAD(, adapter) t4_list;
>
> # nm if_cxgbe.ko | grep t4_list
> 0020 b t4_list.0
>
> gcc used to leave it as t4_list. One problem is that kgdb can't display
> such an item (it interprets the dot as a delimiter between a structure
> and its element). Some of the structures listed at the end look strange
> for other reasons too -- for example, why should there be multiple
> scsi_low_statics.n symbols when there's only one such structure in
> scsi_low.c?
>
> Regards,
> Navdeep
>
>
> full list of affected structures (and some false positives?):
> # nm kernel *.ko | grep '\.[0-9]$'
> 814802d0 b accept_filtlsthd.0
> 8125ca88 b acpi_intr_list.0
> 81292278 b cdevsw_gt_post_list.0
> 812defc8 b clock_adj.0
> 812defd0 b clock_adj.1
> 814d7ac0 b enumerators.0
> 81292460 b eventtimers.0
> 81279680 b feedertab.0
> 81248470 d intr_cpus.0.0
> 814a0378 b keyboard_drivers.0
> 81481c60 b lltables.0
> 814a17a8 b profperiod.1
> 81482280 b route_cb.0
> 81482284 b route_cb.1
> 81482288 b route_cb.2
> 8148228c b route_cb.3
> 812796d0 b sndstat_devlist.0
> 814a17a0 b statperiod.1
> 812925a4 b tstate.0
> 812925a8 b tstate.1
> 8128ab30 b twe_check_bits.lastwarn.0
> 8128ab38 b twe_check_bits.lastwarn.1
> 814804d8 b unp_defers.0
> 81488760 b vm_phys_lookup_lists.0
> 813e7900 b w_hash.0
> 813e80dc b w_hash.2
> 813e58f0 b w_lohash.0
> 813e78dc b w_lohash.2
> 0318 d proto_reg.0
> 031c d proto_reg.1
> 00c0 b fasttrap_procs.0
> 00c8 b fasttrap_procs.1
> 00d0 b fasttrap_procs.2
> 0080 b fasttrap_provs.0
> 0088 b fasttrap_provs.1
> 0090 b fasttrap_provs.2
> 0028 b t3_list.0
> 0050 b t3_uld_list.0
> 0020 b t4_list.0
> 0048 b t4_uld_list.0
> b efdev.0
> 0190 b Counter.0
> 0194 b Counter.1
> 0198 b Counter.2
> 019c b Counter.3
> 0028 b taphead.0
> 1190 b svc_rpc_gss_callbacks.0
> 1198 b svc_rpc_gss_svc_names.0
> 0038 b scsi_low_statics.0
> 003c b scsi_low_statics.1
> 0040 b scsi_low_statics.2
> 0044 b scsi_low_statics.3
> 0048 b scsi_low_statics.4
> 0008 b feedertab.0
> 0098 b sndstat_devlist.0
> 0008 b pcx_info.0
> 000c b pcx_info.1
> 0010 b pcx_info.2
> 0014 b pcx_info.3
> 0018 b pcx_info.4
> 001c b pcx_info.5
> 0020 b pcx_info.6
> 0028 b pcx_info.7
> b twe_check_bits.lastwarn.0
> 0008 b twe_check_bits.lastwarn.1
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: clang mangling some static struct names?
On 11/16/12 13:49, Roman Divacky wrote:
> Yes, it does that. iirc so that you can have things like
>
> void foo(int cond) {
> if (cond) {
> static int i = 7;
> } else {
> static int i = 8;
> }
> }
>
> working correctly.
It's not appending the .n everywhere. And when it does, I don't see any
potential collision that it prevented by doing so. Instead, it looks
like the .n symbol corresponds to the nth element in the structure (so
this is not name mangling in the true sense). I just don't see the
point in doing things this way. It is only making things harder for
debuggers.
Regards,
Navdeep
>
> I dont know why scsi_low_statics is there multiple times.
>
> On Fri, Nov 16, 2012 at 12:36:13PM -0800, Navdeep Parhar wrote:
>> On a very recent clang-built HEAD, I see that some static structures
>> have a ".n" appended to their name. For example, this declaration in
>> the cxgbe driver now results in a t4_list.0 symbol in the KLD:
>>
>> static SLIST_HEAD(, adapter) t4_list;
>>
>> # nm if_cxgbe.ko | grep t4_list
>> 0020 b t4_list.0
>>
>> gcc used to leave it as t4_list. One problem is that kgdb can't display
>> such an item (it interprets the dot as a delimiter between a structure
>> and its element). Some of the structures listed at the end look strange
>> for other reasons too -- for example, why should there be multiple
>> scsi_low_statics.n symbols when there's only one such structure in
>> scsi_low.c?
>>
>> Regards,
>> Navdeep
>>
>>
>> full list of affected structures (and some false positives?):
>> # nm kernel *.ko | grep '\.[0-9]$'
>> 814802d0 b accept_filtlsthd.0
>> 8125ca88 b acpi_intr_list.0
>> 81292278 b cdevsw_gt_post_list.0
>> 812defc8 b clock_adj.0
>> 812defd0 b clock_adj.1
>> 814d7ac0 b enumerators.0
>> 81292460 b eventtimers.0
>> 81279680 b feedertab.0
>> 81248470 d intr_cpus.0.0
>> 814a0378 b keyboard_drivers.0
>> 81481c60 b lltables.0
>> 814a17a8 b profperiod.1
>> 81482280 b route_cb.0
>> 81482284 b route_cb.1
>> 81482288 b route_cb.2
>> 8148228c b route_cb.3
>> 812796d0 b sndstat_devlist.0
>> 814a17a0 b statperiod.1
>> 812925a4 b tstate.0
>> 812925a8 b tstate.1
>> 8128ab30 b twe_check_bits.lastwarn.0
>> 8128ab38 b twe_check_bits.lastwarn.1
>> 814804d8 b unp_defers.0
>> 81488760 b vm_phys_lookup_lists.0
>> 813e7900 b w_hash.0
>> 813e80dc b w_hash.2
>> 813e58f0 b w_lohash.0
>> 813e78dc b w_lohash.2
>> 0318 d proto_reg.0
>> 031c d proto_reg.1
>> 00c0 b fasttrap_procs.0
>> 00c8 b fasttrap_procs.1
>> 00d0 b fasttrap_procs.2
>> 0080 b fasttrap_provs.0
>> 0088 b fasttrap_provs.1
>> 0090 b fasttrap_provs.2
>> 0028 b t3_list.0
>> 0050 b t3_uld_list.0
>> 0020 b t4_list.0
>> 0048 b t4_uld_list.0
>> b efdev.0
>> 0190 b Counter.0
>> 0194 b Counter.1
>> 0198 b Counter.2
>> 019c b Counter.3
>> 0028 b taphead.0
>> 1190 b svc_rpc_gss_callbacks.0
>> 1198 b svc_rpc_gss_svc_names.0
>> 0038 b scsi_low_statics.0
>> 003c b scsi_low_statics.1
>> 0040 b scsi_low_statics.2
>> 0044 b scsi_low_statics.3
>> 0048 b scsi_low_statics.4
>> 0008 b feedertab.0
>> 0098 b sndstat_devlist.0
>> 0008 b pcx_info.0
>> 000c b pcx_info.1
>> 0010 b pcx_info.2
>> 0014 b pcx_info.3
>> 0018 b pcx_info.4
>> 001c b pcx_info.5
>> 0020 b pcx_info.6
>> 0028 b pcx_info.7
>> b twe_check_bits.lastwarn.0
>> 0008 b twe_check_bits.lastwarn.1
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Using PC-Sysinstall for automated network installs of FreeBSD
On Fri, 16 Nov 2012, Mark Saad wrote: All I wanted to share with you my method for network installs of FreeBSD 9.1-RCn . This does not use PC-BSD just stock FreeBSD. This should work on 9.0-RELEASE is known to work on 9.1-RC's and BETA. I decided to use pc-sysinstall in place of bsdinstall as pc-sysinstall supported using a config file that could be passed to the installer much like the old sysinstall way of doing things. This is really nice--thank you! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Using PC-Sysinstall for automated network installs of FreeBSD
On Fri, 16 Nov 2012, Mark Saad wrote:
Useful paths on /export, /export/install/freebsd/9.1/{i386,amd64}
this is the contents of the install media rsync'd to a local filesystem
Do you have a way to choose either i386 or amd64 installs?
5 I changed my rc.conf to start a simple shell script and not the
bsdinstall bits
Maybe you mean "/etc/rc.local" there?
export TERM=vt220
echo "o PC-SYSINSTALL "
exec /conf/picker.sh
Trying to start this from SYSLINUX almost works. My menu config just
does
menu label FreeBSD 9 Install
pxe {serverip}:/usr/tftpboot/images/fbsd9ins/boot/pxeboot
The kernel boots, it gets to
Trying to mount root from nfs: []...
NFS ROOT: {serverip}:/usr/tftpboot/images/fbsd9ins
and then it stops and just sits. NFS mount of that directory works on
another system. Anything obvious I should check? I know pxeboot needs
to be recompiled for some things, but can't recall the details.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Using PC-Sysinstall for automated network installs of FreeBSD
On Fri, 16 Nov 2012, Warren Block wrote: Trying to start this from SYSLINUX almost works. My menu config just does Actually, it does work on a real machine. It stalls on a VirtualBox VM during or after the NFS root mount. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Using PC-Sysinstall for automated network installs of FreeBSD
On Nov 16, 2012, at 8:44 PM, Warren Block wrote: > On Fri, 16 Nov 2012, Warren Block wrote: > >> Trying to start this from SYSLINUX almost works. My menu config just does > > Actually, it does work on a real machine. It stalls on a VirtualBox VM > during or after the NFS root mount. Strange , I will test it on virtualbox when I get some time next week . I did a lot of the testing initially on VMware esxi 4.0 and I did not have any issues related to VM stuff . What version of vbox did you use ? What network interface choice did you use in vbox ? --- Mark saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Fwd: Using PC-Sysinstall for automated network installs of FreeBSD
>
> On Nov 16, 2012, at 8:35 PM, Warren Block wrote:
>
>> On Fri, 16 Nov 2012, Mark Saad wrote:
>>
>>> Useful paths on /export, /export/install/freebsd/9.1/{i386,amd64}
>>> this is the contents of the install media rsync'd to a local filesystem
>>
>> Do you have a way to choose either i386 or amd64 installs?
>
> For my setup no , I just manually change the symlinks .
>
>>
>>> 5 I changed my rc.conf to start a simple shell script and not the
>>> bsdinstall bits
>>
>> Maybe you mean "/etc/rc.local" there?
>>
> Yes that was a typo rc.local
>
>>> export TERM=vt220
>>>
>>> echo "o PC-SYSINSTALL "
>>> exec /conf/picker.sh
>>
>>
>> Trying to start this from SYSLINUX almost works. My menu config just does
>>
>> menu label FreeBSD 9 Install
>> pxe {serverip}:/usr/tftpboot/images/fbsd9ins/boot/pxeboot
>>
>> The kernel boots, it gets to
>>
>> Trying to mount root from nfs: []...
>> NFS ROOT: {serverip}:/usr/tftpboot/images/fbsd9ins
>>
>> and then it stops and just sits. NFS mount of that directory works on
>> another system. Anything obvious I should check? I know pxeboot needs to
>> be recompiled for some things, but can't recall the details.
>
> Well I would check to see if your have a default loader build , if your
> loader was rebuilt with HAS_TFTPSUPPORT or something like that , it will not
> work .
>
> What's in your exports file ? Also what's in your dhcpd config ?
>
> ---
> Mark saad | mark.s...@longcount.org
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Using PC-Sysinstall for automated network installs of FreeBSD
On Fri, 16 Nov 2012, Mark Saad wrote: On Nov 16, 2012, at 8:44 PM, Warren Block wrote: On Fri, 16 Nov 2012, Warren Block wrote: Trying to start this from SYSLINUX almost works. My menu config just does Actually, it does work on a real machine. It stalls on a VirtualBox VM during or after the NFS root mount. Strange , I will test it on virtualbox when I get some time next week . I did a lot of the testing initially on VMware esxi 4.0 and I did not have any issues related to VM stuff . What version of vbox did you use ? What network interface choice did you use in vbox ? VirtualBox 4.1.22, FreeBSD 9-stable amd64 host. Only the "PCnet-FAST III (Am79C973)" can pxe-boot, and only in bridged mode. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[Not this year] Re: FreeBSD in Google Code-In 2012? You can help too!
On Fri, Nov 02, 2012 at 08:13:18PM +, Wojciech A. Koszek wrote: > On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: > > (cross-posted message; please keep discussion on freebsd-hackers@) > > > > Hello, > > > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > > youngest open-source hackers in 13-17yr age range: > > > > http://www.google-melange.com/gci/homepage/google/gci2012 > > > > It was successful. We gained one more FreeBSD developer thanks to that > > (Isabell Long) We're pondering participating in the contest this year as > > well. > > > > For now we only have 25 ideas. We need at least 100. > > > > I felt all members of the FreeBSD community should help, so please submit > > your own Google Code-In 2012 ideas here: > > > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > > > Examples of previously completed tasks: > > > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > > > Those of you who have Wiki access, please spent 2 more minutes and submit > > straight to Wiki: > > > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > > > I plan to send out next e-mail if there's any progress on this project. > > > > Help will be appreciated. > > Hello, > > This is last call for action. > > As for now, we won't qualify. I suggest doc@ and ports@ and www@ and src@ > teams to try to come up with some ideas and add them to Wiki. Most of the > ideas which we have so far are more GSOC-alike. > > Unless we have at least 80 tasks of the "easy"/"medium" type, we'll have to > postpone participating in Code-In for next year. > > Thanks, Hello, We didn't make it this year. I want to thank all the people who submitted (and keep submitting) ideas for our Google Code-In wiki page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks In total I got 61 ideas over e-mail from the web form (lessons learnt: for GSOC, we should also have a web form) All of them should be on the Wiki now. I suggest we keep collecting good ideas and try to make sure this years GSOC will be successful. On the other note--NetBSD guys are in Google Code-In.. Thanks, -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
