iwn does not associates
hi all, since a month the wireless card of the E6400 Dell does not associate with the access point. it used to work fine, before. the config is exactly the same: iwn5150fw + iwn + wpa_supplicant = tkip. starting wpa_supplicant associates a few seconds and reverts to no carrier. here is what i get: sysctl dev.iwn.0.debug=1 iwn_notif_intr: scanning channel 7 status 1 ifconfig wlan0 ... status: no carrier ssid MyDomain channel 7 (2442 MHz 11g) regdomain ETSI country FR authmode OPEN privacy OFF txpower 30 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 thanks in advance for your help. Best regards raoul rm...@free.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: two issues after upgrading to a more up-to-date HEAD
On Thu Jun 16 11, Alexander Best wrote: hi there, i reverted my kernel back to r222890. everything works fine now and both issues i mentioned below dissapeared. i also discovered another issue with the more recent kernel: i was getting errno -128 with a lot of apps. but only the first time i ran them. e.g. with git: 1) -128 2) OK 3) -128 4) OK 5) ... the same with stuff like ./configure or ee(1). first time failures while running or saving; second time it works. this as well was fixed by reverting back to r222890. cheers. alex i'm running HEAD on amd64. yesterday i updated my kernel to r223109. i'm now seeing two issues, which weren't there beforehand: 1) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: SAMSUNG SP2504C VT100-50 ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: SAMSUNG HD103SJ 1AJ10001 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) xpt_action_default: CCB type 0xe not supported xpt_action_default: CCB type 0xe not supported xpt_action_default: CCB type 0xe not supported cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: HL-DT-ST DVDRAM GH24NS50 XP02 Removable CD-ROM SCSI-0 device SMP: AP CPU #1 Launched! cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: cd present [2291664 x 2048 byte records] ^^ i suspect the xpt_action_default messages have been introduced by the recent CAM changes. they appear to be harmless though. 2) dumpon: ioctl(DIOCSKERNELDUMP): Device not configured /etc/rc: WARNING: unable to specify /dev/label/swapfs as a dump device /dev/label/swapfs is a perfect swap partition and worked without any problems beforehand. specifying the device node instead of the label makes no difference: taku% dumpon /dev/ada1p1 dumpon: ioctl(DIOCSKERNELDUMP): Device not configured otaku% gpart show = 34 488394988 ada0 GPT (232G) 34128 1 freebsd-boot (64k) 162 16777216- free - (8.0G) 16777378 471617644 3 freebsd-ufs (224G) =34 1953525101 ada1 GPT (931G) 3420971520 1 freebsd-swap (10G) 20971554 4194304 2 freebsd-ufs (2.0G) 25165858 1928359277 3 freebsd-ufs (919G) otaku% glabel status Name Status Components label/boot N/A ada0p1 gptid/e52df583-e446-11de-bb92-000fb58207c8 N/A ada0p1 ufs/rootfs N/A ada0p3 label/swapfs N/A ada1p1 ufs/varfs N/A ada1p2 ufs/usrfs N/A ada1p3 iso9660/Futurama Season 6 Ep 1-8 720p N/A cd0 cheers. alex -- a13x -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn does not associates
On Friday, June 17, 2011 09:36:46 rm...@free.fr wrote: hi all, since a month the wireless card of the E6400 Dell does not associate with the access point. it used to work fine, before. the config is exactly the same: iwn5150fw + iwn + wpa_supplicant = tkip. starting wpa_supplicant associates a few seconds and reverts to no carrier. here is what i get: sysctl dev.iwn.0.debug=1 iwn_notif_intr: scanning channel 7 status 1 ifconfig wlan0 ... status: no carrier ssid MyDomain channel 7 (2442 MHz 11g) regdomain ETSI country FR authmode OPEN privacy OFF txpower 30 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 thanks in advance for your help. Are you running the latest current? This is a 5350? Can you post your configuration (rc.conf)? If you have a 'ifconfig wlan0 channel 7' somewhere, drop it, I'm aware of an issue regarding fixed channels, but found no clean solution yet. You might also want to try 'ifconfig wlan0 -ht', it might be related to the recent introduction of 11n support for iwn(4). -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn does not associates
On Fri, 17 Jun 2011 10:25:46 +0200 Bernhard Schmidt bschm...@freebsd.org wrote: On Friday, June 17, 2011 09:36:46 rm...@free.fr wrote: hi all, since a month the wireless card of the E6400 Dell does not associate with the access point. it used to work fine, before. the config is exactly the same: iwn5150fw + iwn + wpa_supplicant = tkip. starting wpa_supplicant associates a few seconds and reverts to no carrier. here is what i get: sysctl dev.iwn.0.debug=1 iwn_notif_intr: scanning channel 7 status 1 ifconfig wlan0 ... status: no carrier ssid MyDomain channel 7 (2442 MHz 11g) regdomain ETSI country FR authmode OPEN privacy OFF txpower 30 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 thanks in advance for your help. Are you running the latest current? This is a 5350? yes, head r223138 Can you post your configuration (rc.conf)? sure but nothing is configured in rc.conf except em0 when needed. i join it anyway. If you have a 'ifconfig wlan0 channel 7' somewhere, drop it, I'm aware of an issue regarding fixed channels, but found no clean solution yet. You might also want to try 'ifconfig wlan0 -ht', it might be related to the recent introduction of 11n support for iwn(4). changing the channel does nothing else, nor 'ht' too. setting channel 11 or any channel gives the same result, association for about 30 sec, and lost of carrier. Best Regards Raoul rm...@free.fr # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # pour cacher les commandes exécutées ajouter dans rc: set -x rc_debug=NO #rc_info=YES dumpdev=/dev/ada0s3b dumpdir=/var/crash savecore_flags=-vz #apmd_enable=YES firewall_enable=NO # Set to YES to enable firewall functionality allscreens_flags=-m on #amd_enable=NO # Run amd service with $amd_flags (or NO). defaultrouter=192.168.0.255 entropy_file=YES #firewall_enable=YES # Set to YES to enable firewall functionality firewall_flags= # Flags passed to ipfw when type is a file firewall_logging=YES # Set to YES to enable events logging firewall_quiet=NO# Set to YES to suppress rule display firewall_script=/etc/rc.firewall # Which script to run to set up the firewall firewall_type=SIMPLE # Firewall type (see /etc/rc.firewall) font8x14=iso-8x14 font8x16=iso-8x16 font8x8=iso-8x8 gateway_enable=YES hostname=MyHost #ifconfig_em0=DHCP #ifconfig_em0=inet 192.168.1.2 192.168.1.255 netmask 255.255.255.0 # media 100baseTX inetd_enable=YES ipv6_enable=YES #gif_interfaces=gif0 #gifconfig_gif0=192.168.0.2 11.22.33.44 #ifconfig_gif0_ipv6=inet6 2001:::::2 # 2001:::::1 prefixlen 128 # ipv6_defaultrouter=2001:::::1 keymap=fr.iso.acc ldconfig_insecure=YES ldconfig_paths=/usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib /usr/compat/linux/lib ldconfig_paths_aout=/usr/lib/compat/aout /usr/X11R6/lib/aout /usr/local/lib/aout linux_enable=YES lpd_enable=YES # Run the line printer daemon. lpd_program=/usr/sbin/lpd# path to lpd, if you want a different one. moused_enable=YES #moused_enable=NO moused_type=ps/2 natd_enable=YES #nfs_client_enable=YES #nfs_reserved_port_only=YES #nfs_server_enable=YES portmap_enable=YES #sendmail_enable=YES sshd_enable=YES usbd_enable=YES ntpdate_enable=YES ntp_hosts=195.145.119.188 #ntpdate_flags=ntp1.t-online.de #kern_securelevel=1 #kern_securelevel_enable=YES mixer_enable=YES # preserve your behaviour through reboot fusefs_enable=YES #powerd_enable=YES #powerd_flags=-a hiadaptive # wlans_ath0=wlan0 # vap_create_wlan0=wlanmode sta country US indoor # ifconfig_wlan0=WPA DHCP # ifconfig_bge0_alias0=inet6 2001:418:1::40/64 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: graid hit the tree
On Thu, 2011-03-24 at 23:48 +0200, Alexander Motin wrote: Hi. I've just committed the new GEOM-based software RAID driver (graid) into the HEAD [1]. Brave testers are welcome. :) 1. http://svn.freebsd.org/viewvc/base?view=revisionrevision=219974 One question. I'm very happy with the performance of the ahci subsystem, it is measurably faster against the old ATA subsystem on modern hardware. I also really appreciate the compatibility shims to aid migration from the adX style numbering to adaX. On every system I've migrated so far, this mapping has worked flawlessly. Is there any chance that mapping from /dev/arX - /dev/raid/r0 etc could also be done? One thing that I have found is that it can be hard to determine from the dmesg exactly where raid partitions will appear. It would be wonderful if devices similar to the adX devices could be made, for any graid devices found. Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: graid hit the tree
On Fri, Jun 17, 2011 at 6:09 AM, Gavin Atkinson ga...@freebsd.org wrote: On Thu, 2011-03-24 at 23:48 +0200, Alexander Motin wrote: Hi. I've just committed the new GEOM-based software RAID driver (graid) into the HEAD [1]. Brave testers are welcome. :) 1. http://svn.freebsd.org/viewvc/base?view=revisionrevision=219974 One question. I'm very happy with the performance of the ahci subsystem, it is measurably faster against the old ATA subsystem on modern hardware. I also really appreciate the compatibility shims to aid migration from the adX style numbering to adaX. On every system I've migrated so far, this mapping has worked flawlessly. Is there any chance that mapping from /dev/arX - /dev/raid/r0 etc could also be done? One thing that I have found is that it can be hard to determine from the dmesg exactly where raid partitions will appear. It would be wonderful if devices similar to the adX devices could be made, for any graid devices found. For this case, would it make more sense to advise folks to use devfs.conf ? Otherwise one would need to tell geom to talk ataraid a bit, which may or may not confuse some consumers. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: udav: vendor 0x0fe6, product: 0x9700
Hi all
I was venturing more on the idea of running this adapter, I decided to
test on OpenBSD 4.9
OpenBSD 4.9 RELEASE is already entry for id 0x8180, equal to FreeBSD
9.0-CURRENT.
What I did (see attached diff file) was to do the same, I tried to do
in freebsd, add the id of the new adapter based on 0x8180
And everything worked as I expected, I managed to get a MAC address
and use the ifconfig output as below:
udav0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
lladdr 00:e0:4c:53:44:58
priority: 0
media: Ethernet none
inet6 fe80::2e0:4cff:fe53:4458%udav0 prefixlen 64 scopeid 0x5
Do I have to specify the id somewhere else, some input to the PHY?
Thanks
2011/6/10 Luiz Gustavo S. Costa lgco...@pfsense.org:
Hi Rick,
2011/6/10 Rick van der Zwet i...@rickvanderzwet.nl:
On 10 June 2011 14:17, Luiz Gustavo S. Costa lgco...@pfsense.org wrote:
I'm trying to add a new product id [1] to the driver udav and am
having a little trouble.
At first, this is similar to id 0x8180 and there should be no
problems, but I still can not get a PHY for it.
Assuming you mean 0x8181 --looking at your patch-- How do you know
they have similar chip-sets? Can you get the full interface
description list for both to see if they have the same endpoints:
usbconfig dump_all_config_desc
Yes... I will find here the link that describes this:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commit;h=67158cebde60edb1a11cf4743f1cb9ded847c5fc
Can someone help me?
...
About adapter:
[1] http://www.luizgustavo.pro.br/~lgcosta/jp1080/
Looking at the picture these kind of USB dongles (various chipsets)
tend to die. I suspect the build quality is not that great. Just
checking you did check it the device is functioning properly using the
official (linux) drivers?
Yes, it's a very cheap adapter, can be found on ebay easily.
And yes, he normally works in linux, I am posting a link to the code
and it is observed, the only difference are exactly the entries id
of the product.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=blob;f=drivers/net/usb/dm9601.c;h=5002f5be47be7dcbd95e0fd9cee2a80910046a81;hb=HEAD
Br. /Rick
--
http://rickvanderzwet.nl
Thanks
--
/\ Luiz Gustavo S. Costa
/ \ Programmer at BSD Perimeter
/ \ /\/\/\ Visit the pfSense Project
/ \ \ \ http://www.pfsense.org
-
BSD da serra carioca, Teresopolis (visite: http://miud.in/Inv)
Contatos: luizgust...@luizgustavo.pro.br / lgco...@pfsense.org
Blog: http://www.luizgustavo.pro.br
--
/\ Luiz Gustavo S. Costa
/ \ Programmer at BSD Perimeter
/ \ /\/\/\ Visit the pfSense Project
/ \ \ \ http://www.pfsense.org
-
BSD da serra carioca, Teresopolis (visite: http://miud.in/Inv)
Contatos: luizgust...@luizgustavo.pro.br / lgco...@pfsense.org
Blog: http://www.luizgustavo.pro.br
diff -r 18f25adaa9dd dev/usb/if_udav.c
--- a/dev/usb/if_udav.c Fri Jun 17 10:39:30 2011 -0300
+++ b/dev/usb/if_udav.c Fri Jun 17 10:43:51 2011 -0300
@@ -167,7 +167,8 @@
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ST268 }, 0 },
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ZT6688 }, 0 },
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ADM8515 }, 0 },
- {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601 }, 0 }
+ {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601 }, 0 },
+ {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_JP1082 }, 0 }
};
#define udav_lookup(v, p) ((struct udav_type *)usb_lookup(udav_devs, v, p))
diff -r 18f25adaa9dd dev/usb/usbdevs
--- a/dev/usb/usbdevs Fri Jun 17 10:39:30 2011 -0300
+++ b/dev/usb/usbdevs Fri Jun 17 10:43:51 2011 -0300
@@ -3744,6 +3744,7 @@
/* Unknown vendor 4 */
product UNKNOWN4 DM96010x8101 DM9601
+product UNKNOWN4 JP1082 0x9700 JP1082
/* Unknown vendor 5 */
product UNKNOWN5 NF_RIC0x0001 NF RIC
diff -r 18f25adaa9dd dev/usb/usbdevs.h
--- a/dev/usb/usbdevs.h Fri Jun 17 10:39:30 2011 -0300
+++ b/dev/usb/usbdevs.h Fri Jun 17 10:43:51 2011 -0300
@@ -3751,6 +3751,7 @@
/* Unknown vendor 4 */
#defineUSB_PRODUCT_UNKNOWN4_DM9601 0x8101 /* DM9601 */
+#define USB_PRODUCT_UNKNOWN4_JP1082 0x9700 /* DM9601 */
/* Unknown vendor 5 */
#defineUSB_PRODUCT_UNKNOWN5_NF_RIC 0x0001 /* NF RIC */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SU+J: negative used diskspace (for a while)
Hi, I found a possible issue with SU+J on recent versions of -CURRENT. After deleting a large file hierarchy (copy of /usr/src, ~1.5 Gbyte), df reports a negative number of blocks Used for a while. I am using a GENERIC kernel (r223184) on an amd64 platform. The hardware is relatively simple: Intel DP965LT mainboard with a Q6600 CPU, 8 Gbyte RAM and two Samsung 501LJ 500 Gbyte SATA disks. The issue can be demonstrated by copying /usr/src to the current directory (cp -R /usr/src .) and running the following script to delete the copy and print the free space at 10 second intervals: #!/bin/sh df . time rm -rf src echo 'src is gone ...' while true do df . | tail -1 sleep 10 done This yields the following output: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ada0s1g 416144900 1612066 381241242 0%/home 51.21 real 1.00 user17.38 sys src is gone ... /dev/ada0s1g 416144900 -164692 383018000-0%/home /dev/ada0s1g 416144900 -165082 383018390-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 32910 382820398 0%/home /dev/ada0s1g 416144900 32910 382820398 0%/home So it takes more than a minute before the disk space is back to normal values. After disabling journaling (tunefs -j disable) I get the following output: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ada0s1g 416144900 1579284 381274024 0%/home 35.40 real 0.96 user13.32 sys src is gone ... /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home which is as it should be. The problem also does not occur with journaling enabled when I revert to r222723. Is anybody else seeing these weird phenomena? Could this be related to the recent changes to UFS? Kind regards, Hans Ottevanger ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: graid hit the tree
2011/6/17 Gavin Atkinson ga...@freebsd.org: Is there any chance that mapping from /dev/arX - /dev/raid/r0 etc could also be done? so this is lying yet? UPDATING 20110424: ataraid(4) functionality is now supported by the RAID GEOM class. To use it you can load geom_raid kernel module and use graid(8) tool for management. Instead of /dev/arX device names, use /dev/raid/rX. BTW, amr controllers seem not hiding real device, I got somethings like ar0, ad4, ad6 in ATA era. For solving device name issue, usually I use label, but the unhided device make label duplicated, anyway to tune it? Thanks, Buganini ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037 144590601.0098392393 1495969404 144473671.0090225853 As you can see, HPET increases normally (within errors from sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally erratic (and too low). I don't know how this can happen, though. :-( I need some time to figure it out. Even though sleep states have been disabled in the past when on AC power, they seem to have mysteriously been enabled. Perhaps this accounts for the strangeness: /etc/rc.conf performance_cx_lowest=HIGH performance_cpu_freq=HIGH economy_cx_lowest=LOW economy_cpu_freq=HIGH [mini] /usr/home/ianf $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1600 dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 300/225 200/150 100/75 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us Pulling the power cord and re-inserting it has the cx_lowest correctly trantsition to C1 and then TSC-low behaves properly as the system timecounter. But, time will be wierd when on battery. In light of this, I doubt the patch in your other email will have any effect. Perhaps the thing to do is to have the timecounter code aware of the lowest Cx sleep state and to pick best time counter for that state and to re-evaluate the choice on cx_lowest transitions. ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for C2 and lower. Hmm... So, you are saying this CPU model is P-state invariant but not C-state invariant (i.e., it stops incrementing in C2 state and above). If that's the case, it is really useless for timecounter. :-( What happens if you set it to C2, i.e., economy_cx_lowest=C2 In other words, does it really stop in C2-state? Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037144590601.0098392393 1495969404144473671.0090225853 As you can see, HPET increases normally (within errors from sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally erratic (and too low). I don't know how this can happen, though. :-( I need some time to figure it out. Even though sleep states have been disabled in the past when on AC power, they seem to have mysteriously been enabled. Perhaps this accounts for the strangeness: /etc/rc.conf performance_cx_lowest=HIGH performance_cpu_freq=HIGH economy_cx_lowest=LOW economy_cpu_freq=HIGH [mini] /usr/home/ianf $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1600 dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 300/225 200/150 100/75 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us Pulling the power cord and re-inserting it has the cx_lowest correctly trantsition to C1 and then TSC-low behaves properly as the system timecounter. But, time will be wierd when on battery. In light of this, I doubt the patch in your other email will have any effect. Perhaps the thing to do is to have the timecounter code aware of the lowest Cx sleep state and to pick best time counter for that state and to re-evaluate the choice on cx_lowest transitions. ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for C2 and lower. Hmm... So, you are saying this CPU model is P-state invariant but not C-state invariant (i.e., it stops incrementing in C2 state and above). If that's the case, it is really useless for timecounter. :-( What happens if you set it to C2, i.e., economy_cx_lowest=C2 In other words, does it really stop in C2-state? The folowing is with timecounter=HPET, just to see what the effect on TSC-low is. It looks like it does stop in C3. hw.acpi.cpu.cx_lowest=C3 [mini] /usr/home/ianf $ sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1)); sysctl kern.timecounter.tc.TSC-low.counter; sleep 1; done' kern.timecounter.tc.TSC-low.counter: 722687906 kern.timecounter.tc.TSC-low.counter: 724328394 kern.timecounter.tc.TSC-low.counter: 726038743 kern.timecounter.tc.TSC-low.counter: 727690855 kern.timecounter.tc.TSC-low.counter: 729245616 kern.timecounter.tc.TSC-low.counter: 730786569 kern.timecounter.tc.TSC-low.counter: 732398571 kern.timecounter.tc.TSC-low.counter: 733910987 kern.timecounter.tc.TSC-low.counter: 735711469 kern.timecounter.tc.TSC-low.counter: 737368279 hw.acpi.cpu.cx_lowest=C2 kern.timecounter.tc.TSC-low.counter: 897318486 kern.timecounter.tc.TSC-low.counter: 909873821 kern.timecounter.tc.TSC-low.counter: 922416894 kern.timecounter.tc.TSC-low.counter: 934960462 kern.timecounter.tc.TSC-low.counter: 947504154 kern.timecounter.tc.TSC-low.counter: 960050573 kern.timecounter.tc.TSC-low.counter: 972590754 kern.timecounter.tc.TSC-low.counter: 985133990 kern.timecounter.tc.TSC-low.counter: 997677052 kern.timecounter.tc.TSC-low.counter: 1010220299 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: TLS bug?
On Thu, Jun 16, 2011 at 03:53:19AM -0400, Nathaniel W Filardo wrote:
Atcht; it's late. I forgot to mention that this system is a sparc64 V240
2-way SMP machine. It's running a kernel from 9.0-CURRENT r222833+262af52:
Tue Jun 7 18:47:35 EDT 2011 and a userland from a little later.
Sorry about that.
--nwf;
On Thu, Jun 16, 2011 at 03:31:38AM -0400, Nathaniel W Filardo wrote:
I have a few applications (bonnie++ and mysql, specifically, both from
ports) which trip over the assertion in
lib/libc/stdlib/malloc.c:/^_malloc_thread_cleanup that
assert(tcache != (void *)(uintptr_t)1);
I have patched malloc.c thus:
--- a/lib/libc/stdlib/malloc.c
+++ b/lib/libc/stdlib/malloc.c
@@ -1108,7 +1108,7 @@ static __thread arena_t *arenas_map
TLS_MODEL;
#ifdef MALLOC_TCACHE
/* Map of thread-specific caches. */
-static __thread tcache_t *tcache_tls TLS_MODEL;
+__thread tcache_t *tcache_tls TLS_MODEL;
/*
* Number of cache slots for each bin in the thread cache, or 0 if tcache
* is
@@ -6184,10 +6184,17 @@ _malloc_thread_cleanup(void)
#ifdef MALLOC_TCACHE
tcache_t *tcache = tcache_tls;
+fprintf(stderr, _m_t_c for %d:%lu with %p\n,
+ getpid(),
+ (unsigned long) _pthread_self(),
+ tcache);
+
if (tcache != NULL) {
- assert(tcache != (void *)(uintptr_t)1);
- tcache_destroy(tcache);
- tcache_tls = (void *)(uintptr_t)1;
+ /* assert(tcache != (void *)(uintptr_t)1); */
+ if((uintptr_t)tcache != (uintptr_t)1) {
+ tcache_destroy(tcache);
+ tcache_tls = (void *)(uintptr_t)1;
+ }
and libthr/thread/thr_create.c thus:
--- a/lib/libthr/thread/thr_create.c
+++ b/lib/libthr/thread/thr_create.c
@@ -243,6 +243,8 @@ create_stack(struct pthread_attr *pattr)
return (ret);
}
+extern __thread void *tcache_tls;
+
static void
thread_start(struct pthread *curthread)
{
@@ -280,6 +282,11 @@ thread_start(struct pthread *curthread)
curthread-attr.stacksize_attr;
#endif
+fprintf(stderr, t_s for %d:%lu with %p\n,
+getpid(),
+(unsigned long) _pthread_self(),
+tcache_tls);
+
/* Run the current thread's start routine with argument: */
_pthread_exit(curthread-start_routine(curthread-arg));
to attempt to debug this issue. With those changes in place, bonnie++'s
execution looks like this:
[...]
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
t_s for 79654:1086343168 with 0x0
t_s for 79654:1086345216 with 0x0
t_s for 79654:1086346240 with 0x0
t_s for 79654:1086347264 with 0x0
t_s for 79654:1086344192 with 0x0
start 'em...done...done...done...done..._m_t_c for 79654:1086344192 with
0x41404400
_m_t_c for 79654:1086346240 with 0x40d2c400
_m_t_c for 79654:1086343168 with 0x41404200
_m_t_c for 79654:1086345216 with 0x41804200
done...
_m_t_c for 79654:1086347264 with 0x41004200
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
1.96,1.96,hydra.priv.oc.ietfng.org,1,1308217772,10M,,7,81,2644,7,3577,14,34,93,+,+++,773.7,61,16,,,
,,2325,74,13016,99,2342,86,3019,91,11888,99,2184,89,16397ms,1237ms,671ms,2009ms,177us,1305ms,489ms,1029
us,270ms,140ms,53730us,250ms
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
t_s for 79654:1086343168 with 0x1
t_s for 79654:1086346240 with 0x1
t_s for 79654:1086345216 with 0x1
t_s for 79654:1086347264 with 0x1
t_s for 79654:1086344192 with 0x1
start 'em...done...done...done...done...done...
_m_t_c for 79654:1086347264 with 0x1
_m_t_c for 79654:1086344192 with 0x1
_m_t_c for 79654:1086343168 with 0x1
[...]
So what seems to be happening is that the TLS area is being set up
incorrectly, eventually: rather than zeroing the tcache_tls value, it is
being set to 1, which means no tcache is ever allocated, so when we get
around to exiting, the assert trips.
Unfortunately, setting a breakpoint on __libc_allocate_tls seems to do bad
things to the kernel (inducing a SIR without any panic message). I am
somewhat at a loss; help?
Using bonnie++ I can't reproduce this (didn't try mysql) but I have
some TLS fixes for libthr I forgot about but could be relevant here
(most actually date back to 2008 when the base binutils
Re: SU+J: negative used diskspace (for a while)
On Fri, Jun 17, 2011 at 05:34:15PM +0200, Hans Ottevanger wrote: Hi, I found a possible issue with SU+J on recent versions of -CURRENT. After deleting a large file hierarchy (copy of /usr/src, ~1.5 Gbyte), df reports a negative number of blocks Used for a while. Yes, thank you. This is a known issue and I believe that it is on Jeff's to-do list. - Peter ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Friday 17 June 2011 01:45 pm, Ian FREISLICH wrote: Jung-uk Kim wrote: On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037 144590601.0098392393 1495969404 144473671.0090225853 As you can see, HPET increases normally (within errors from sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally erratic (and too low). I don't know how this can happen, though. :-( I need some time to figure it out. Even though sleep states have been disabled in the past when on AC power, they seem to have mysteriously been enabled. Perhaps this accounts for the strangeness: /etc/rc.conf performance_cx_lowest=HIGH performance_cpu_freq=HIGH economy_cx_lowest=LOW economy_cpu_freq=HIGH [mini] /usr/home/ianf $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1600 dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 300/225 200/150 100/75 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us Pulling the power cord and re-inserting it has the cx_lowest correctly trantsition to C1 and then TSC-low behaves properly as the system timecounter. But, time will be wierd when on battery. In light of this, I doubt the patch in your other email will have any effect. Perhaps the thing to do is to have the timecounter code aware of the lowest Cx sleep state and to pick best time counter for that state and to re-evaluate the choice on cx_lowest transitions. ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for C2 and lower. Hmm... So, you are saying this CPU model is P-state invariant but not C-state invariant (i.e., it stops incrementing in C2 state and above). If that's the case, it is really useless for timecounter. :-( What happens if you set it to C2, i.e., economy_cx_lowest=C2 In other words, does it really stop in C2-state? The folowing is with timecounter=HPET, just to see what the effect on TSC-low is. It looks like it does stop in C3. hw.acpi.cpu.cx_lowest=C3 [mini] /usr/home/ianf $ sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1)); sysctl kern.timecounter.tc.TSC-low.counter; sleep 1; done' kern.timecounter.tc.TSC-low.counter: 722687906 kern.timecounter.tc.TSC-low.counter: 724328394 kern.timecounter.tc.TSC-low.counter: 726038743 kern.timecounter.tc.TSC-low.counter: 727690855 kern.timecounter.tc.TSC-low.counter: 729245616 kern.timecounter.tc.TSC-low.counter: 730786569 kern.timecounter.tc.TSC-low.counter: 732398571 kern.timecounter.tc.TSC-low.counter: 733910987 kern.timecounter.tc.TSC-low.counter: 735711469 kern.timecounter.tc.TSC-low.counter: 737368279 hw.acpi.cpu.cx_lowest=C2 kern.timecounter.tc.TSC-low.counter: 897318486 kern.timecounter.tc.TSC-low.counter: 909873821 kern.timecounter.tc.TSC-low.counter: 922416894 kern.timecounter.tc.TSC-low.counter: 934960462 kern.timecounter.tc.TSC-low.counter: 947504154 kern.timecounter.tc.TSC-low.counter: 960050573 kern.timecounter.tc.TSC-low.counter: 972590754 kern.timecounter.tc.TSC-low.counter: 985133990 kern.timecounter.tc.TSC-low.counter: 997677052 kern.timecounter.tc.TSC-low.counter: 1010220299 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,M OVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Thanks for the info, it confirmed my speculation. Somewhere from an Intel manual, I think I read TSC stops when DPSLP# pin is asserted for Core/Core2/Atom processors and I guess that means entering C3 stops TSC. :-( Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: atkbdc broken on current ?
On Friday, May 06, 2011 11:47:33 am John Baldwin wrote: On Thursday, May 05, 2011 5:04:54 pm Damjan Marion wrote: On May 5, 2011, at 7:43 PM, John Baldwin wrote: On Thursday, May 05, 2011 9:21:04 am Damjan Marion wrote: Hi, I have issue with old HP DL380G3 server. When I use ILO virtual console to manage server. Seems that 9-CURRENT fails to detect atkbdc. When I boot 8.2-RELEASE it works well. 8.2 dmesg shows: atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 9.0: atkbdc0: Keyboard controller (i8042) failed to probe at port 0x60 on isa0 Is this a known issue? Should I enable some additional outputs, like KBDIO_DEBUG? I suspect this is a resource issue stemming from changes I made to the acpi(4) bus driver quite a while ago to make it use rman_reserve_resource(). Can you capture a full verbose dmesg from 9 along with devinfo -rv and devinfo -ur output from 9? Here it is: http://web.me.com/dmarion/atkbdc.txt Ohh, hmm. Your BIOS has done odd things: isab0 pnpinfo vendor=0x1166 device=0x0201 subvendor=0x1166 subdevice=0x0201 class=0x060100 at slot=15 function=0 handle=\_SB_.PCI0.IBRG isa0 I/O ports: 0x0-0xf 0x20-0x21 0x40-0x43 0x60 0x61 0x64 0x80-0x8f 0xa0-0xa1 0xc0-0xdf 0x4d6 Still, I don't know how the ISA bus is actually allocating resources. Can you add some code to the x86 nexus driver to drop into kdb when it receives a SYS_RES_IOPORT allocation request from isa0 and get a stack trace from DDB and reply with the trace? So I think I just found the explanation for this and I think the change I just committed will fix your system: Author: jhb Date: Fri Jun 17 21:19:01 2011 New Revision: 223207 URL: http://svn.freebsd.org/changeset/base/223207 Log: Don't create a device_t object or parse current resources (via _CRS) for ACPI Device() objects that do not have any device IDs available via the _HID or _CID methods. Without a device ID a device driver cannot attach to the device anyway. Namespace objects that are devices but not of type ACPI_TYPE_DEVICE are not affected. A few BIOSes have also attached a _CRS method to a PCI device to allocate resources that are not managed via a BAR. With the previous code those resources are allocated from acpi0 directly which can interfere with the new PCI-PCI bridge driver (since the PCI device in question may be behind a bridge and its resources should be allocated from that bridge's windows instead). The resources were also orphaned and and would end up associated with some other random device whose device_t reused the pointer of the original ACPI-enumerated device (after it was free'd by the ACPI PCI bus driver) in devinfo output which was confusing. If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus driver to do that in the future and associate the resources with the proper device object respecting PCI-PCI bridges, etc. Note that with this change the ACPI PCI bus driver no longer has to delete ACPI-enumerated device_t devices that mirror PCI devices since they should in general not exist. There are rare cases when a BIOS will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given a _HID for a system resource device). In that case we leave both the ACPI and PCI-enumerated device_t objects around just as in the previous code. Modified: head/sys/dev/acpica/acpi.c head/sys/dev/acpica/acpi_pci.c -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: TLS bug?
On Fri, Jun 17, 2011 at 03:31:29PM -0400, Nathaniel W Filardo wrote: On Fri, Jun 17, 2011 at 08:07:13PM +0200, Marius Strobl wrote: Using bonnie++ I can't reproduce this (didn't try mysql) but I have I seem to have good luck reproducing it with -r 5 -s 10 -x 10 by about the third iteration. Ok, with these parameters I can reproduce it. some TLS fixes for libthr I forgot about but could be relevant here (most actually date back to 2008 when the base binutils didn't support GNUTLS for sparc64 so I couldn't test them easily). Could you please give a libthr build with the following patch a try? http://people.freebsd.org/~marius/libthr_sparc64.diff Concurrent runs both with and without those diffs still asserted. Interestingly, libc's .tbss section, even after the assertion, is still full of zeros, so it looks like something stranger than a wild-write back to .tbss. I'll go diving through the tls allocation code again when I get a minute. In combination with the below patch bonnie++ survived 100 iterations here. I'm not sure what this means though as I don't have much knowledge about TLS, I merely implemented the necessary relocations. Could be that malloc() actually requires the initial exec model for variant II. Unfortunately, it's not documented why it was added for x86. Jason, can you shed some light on this? Marius Index: malloc.c === --- malloc.c(revision 219535) +++ malloc.c(working copy) @@ -234,7 +234,7 @@ #ifdef __sparc64__ # define LG_QUANTUM 4 # define LG_SIZEOF_PTR3 -# define TLS_MODEL/* default */ +# define TLS_MODEL__attribute__((tls_model(initial-exec))) #endif #ifdef __amd64__ # define LG_QUANTUM 4 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Hang During Startup on ZFS Boot (intermittent)
Hello, I have installed 9-Current from the May 12 2011 iso that was available and I used a ZFS boot disk and gpt partition as described. I have a problem on reboot that booting stalls during listing of the SMP CPU start-up (?) after listing the 15th or 16th CPU. I must power-down the computer to initiate a new restart once it stalls. Sometimes I need to power-down two or three times before it will proceed through the start-up. There does not appear to be anything written to a log file during failed start-ups. How would I go about attempting to find out why this is occurring (presuming it is not a known problem)? It makes me nervous that powering down like that will eventually cause a problem preventing any reboot. I have posted the most recent system log from a boot. Thanks for any pointers in advance. Aric --- FreeBSD freeenv 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu May 12 15:34:46 UTC 2011 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 --- 2011-06-16 10:40:36 freeenv syslogd kernel boot file is /boot/kernel/kernel 2011-06-16 10:40:36 freeenv kernel Copyright (c) 1992-2011 The FreeBSD Project. 2011-06-16 10:40:36 freeenv kernel Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 2011-06-16 10:40:36 freeenv kernel The Regents of the University of California. All rights reserved. 2011-06-16 10:40:36 freeenv kernel FreeBSD is a registered trademark of The FreeBSD Foundation. 2011-06-16 10:40:36 freeenv kernel FreeBSD 9.0-CURRENT #0: Thu May 12 15:34:46 UTC 2011 2011-06-16 10:40:36 freeenv kernel r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 2011-06-16 10:40:36 freeenv kernel WARNING: WITNESS option enabled, expect reduced performance. 2011-06-16 10:40:36 freeenv kernel CPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz (2793.05-MHz K8-class CPU) 2011-06-16 10:40:36 freeenv kernel Origin = GenuineIntel Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 2011-06-16 10:40:36 freeenv kernel Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE 2011-06-16 10:40:36 freeenv kernel Features2=0x9ee3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT 2011-06-16 10:40:36 freeenv kernel AMD Features=0x2c100800SYSCALL,NX,Page1GB,RDTSCP,LM 2011-06-16 10:40:36 freeenv kernel AMD Features2=0x1LAHF 2011-06-16 10:40:36 freeenv kernel TSC: P-state invariant, performance statistics 2011-06-16 10:40:36 freeenv kernel real memory = 51539607552 (49152 MB) 2011-06-16 10:40:36 freeenv kernel avail memory = 49642921984 (47343 MB) 2011-06-16 10:40:36 freeenv kernel Event timer LAPIC quality 600 2011-06-16 10:40:36 freeenv kernel ACPI APIC Table: 032610 APIC1143 2011-06-16 10:40:36 freeenv kernel FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs 2011-06-16 10:40:36 freeenv kernel FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads 2011-06-16 10:40:36 freeenv kernel cpu0 (BSP): APIC ID: 0 2011-06-16 10:40:36 freeenv kernel cpu1 (AP): APIC ID: 1 2011-06-16 10:40:36 freeenv kernel cpu2 (AP): APIC ID: 2 2011-06-16 10:40:36 freeenv kernel cpu3 (AP): APIC ID: 3 2011-06-16 10:40:36 freeenv kernel cpu4 (AP): APIC ID: 4 2011-06-16 10:40:36 freeenv kernel cpu5 (AP): APIC ID: 5 2011-06-16 10:40:36 freeenv kernel cpu6 (AP): APIC ID: 16 2011-06-16 10:40:36 freeenv kernel cpu7 (AP): APIC ID: 17 2011-06-16 10:40:36 freeenv kernel cpu8 (AP): APIC ID: 18 2011-06-16 10:40:36 freeenv kernel cpu9 (AP): APIC ID: 19 2011-06-16 10:40:36 freeenv kernel cpu10 (AP): APIC ID: 20 2011-06-16 10:40:36 freeenv kernel cpu11 (AP): APIC ID: 21 2011-06-16 10:40:36 freeenv kernel cpu12 (AP): APIC ID: 32 2011-06-16 10:40:36 freeenv kernel cpu13 (AP): APIC ID: 33 2011-06-16 10:40:36 freeenv kernel cpu14 (AP): APIC ID: 34 2011-06-16 10:40:36 freeenv kernel cpu15 (AP): APIC ID: 35 2011-06-16 10:40:36 freeenv kernel cpu16 (AP): APIC ID: 36 2011-06-16 10:40:36 freeenv kernel cpu17 (AP): APIC ID: 37 2011-06-16 10:40:36 freeenv kernel cpu18 (AP): APIC ID: 48 2011-06-16 10:40:36 freeenv kernel cpu19 (AP): APIC ID: 49 2011-06-16 10:40:36 freeenv kernel cpu20 (AP): APIC ID: 50 2011-06-16 10:40:36 freeenv kernel cpu21 (AP): APIC ID: 51 2011-06-16 10:40:36 freeenv kernel cpu22 (AP): APIC ID: 52 2011-06-16 10:40:36 freeenv kernel cpu23 (AP): APIC ID: 53 2011-06-16 10:40:36 freeenv kernel ioapic1: Changing APIC ID to 7 2011-06-16 10:40:36 freeenv kernel ioapic0 Version 2.0 irqs 0-23 on motherboard 2011-06-16 10:40:36 freeenv kernel ioapic1 Version 2.0 irqs 24-47 on motherboard 2011-06-16 10:40:36 freeenv kernel kbd1 at kbdmux0 2011-06-16 10:40:36 freeenv kernel acpi0: NEC on
Re: Hang During Startup on ZFS Boot (intermittent)
On Friday 17 June 2011 07:54 pm, Aric Gregson wrote: Hello, I have installed 9-Current from the May 12 2011 iso that was available and I used a ZFS boot disk and gpt partition as described. I have a problem on reboot that booting stalls during listing of the SMP CPU start-up (?) after listing the 15th or 16th CPU. I must power-down the computer to initiate a new restart once it stalls. Sometimes I need to power-down two or three times before it will proceed through the start-up. There does not appear to be anything written to a log file during failed start-ups. How would I go about attempting to find out why this is occurring (presuming it is not a known problem)? It makes me nervous that powering down like that will eventually cause a problem preventing any reboot. I have posted the most recent system log from a boot. Thanks for any pointers in advance. [SNIP] I believe the problem was fixed by the following commit: http://svn.freebsd.org/changeset/base/222032 Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hang During Startup on ZFS Boot (intermittent)
On Friday, June 17, 2011 05:04:44 PM Jung-uk Kim wrote: I believe the problem was fixed by the following commit: http://svn.freebsd.org/changeset/base/222032 Thank you very much. Now for a stupid question, do I just resync my /usr/src with 9-Current and rebuild? Aric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Patch] [regression] libvgl and r197330 (kbd)
On Fri, Sep 25, 2009 at 8:39 AM, Ed Schouten e...@80386.nl wrote:
Hi all,
* Kostik Belousov kostik...@gmail.com wrote:
Ah, it seems SDL also calls GIO_KEYMAP. Just rebuilding SDL should fix
this. I promised to add a message to UPDATING as well, so I'll also
mention SDL should be rebuilt as well.
I consider this as a very strong argument to keep the existing ioctl
as is, and provide new ioctl that takes new table.
I've attached a patch that should restore binary compatibility. I first
thought this wasn't really needed, because most applications would use
K_RAW instead of K_XLATE anyway.
Just breaking binary compatibility with kbdcontrol(1) wouldn't have been
too bad, but it turns out things like SDL use this as well. I've
attached a patch that should restore binary compatibility. Anyone
interested in testing this before I commit it to SVN?
Replying to ancient history, it looks like this patch never got
committed? The Debian kFreeBSD folks have run into a similar issue:
http://lists.debian.org/debian-bsd/2011/06/msg00238.html
proposing
===
Upstream could do it properly, without ABI breaking, i.e. by
#define GIO_KEYMAP_OLD _IOR('k', 6, keymap_t)
#define PIO_KEYMAP_OLD _IOW('k', 7, keymap_t)
...
#define GIO_KEYMAP _IO('k', 16)
#define PIO_KEYMAP _IO('k', 17)
===
Something to keep the ABI between 8 and 9 is probably still useful,
even at this juncture.
-Ben Kaduk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
