Re: Is international support broken is msdosfs file system driver?
Shaowei Wang (wsw) wrote: try -L zh_CN.euc . zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work. I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of them worked. Nut the garbage displayed by 'ls' changes depending on the one used. Windows file system use a different way to encode i18n chars, like code page. There is a hacked version of msdosfs which can support UTF-8 locale. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 and for using: mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount I've tried it and it's work. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 doesn't exist. Somehow in Windows the disk is read correctly without specifying any additional options. So I guess this is a serious defect that msdosfs driver can't do the same. Yuri ___ 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: Is international support broken is msdosfs file system driver?
On Tue, Apr 7, 2009 at 2:00 PM, Yuri y...@rawbw.com wrote: Shaowei Wang (wsw) wrote: try -L zh_CN.euc . zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work. I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of them worked. Nut the garbage displayed by 'ls' changes depending on the one used. You locale should be same as the param which passed to the -L option and make sure your xterm(rxvt) can display chinese chars. Windows file system use a different way to encode i18n chars, like code page. There is a hacked version of msdosfs which can support UTF-8 locale. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 and for using: mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount I've tried it and it's work. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 doesn't exist. Please try the attached file. Somehow in Windows the disk is read correctly without specifying any additional options. So I guess this is a serious defect that msdosfs driver can't do the same. I think so. Yuri ___ 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: watchdog: hw+sw?
I've been thinking about this some more. So, clearly, sw watchdog is different from all the hw watchdogs (that I know about) in that it tries to take a debugging action as opposed to a straightforward recovery action. As such it currently doesn't make much sense to mix sw and hw watchdogs together, because in the case of a problem they would fire at close times and a (typical) hw watchdog would override sw watchdog. This is fine as it is, maybe a small warning in a case of such mix would be nice too. However, I think that it should be possible to use sw watchdog as a special primary watchdog and hw watchdog(s) as failsafe watchdogs for the primary one. I see two general approaches at the moment: 1. hw watchdog has only slightly longer timeout than the sw watchdog (by a configurable delta), the watchdogs gets patted at the same time; if the sw wd fires and is able to proceed, it first disables hw watchdog(s) and the performs its duty (panic, ddb); 2. hw watchdog has substantially longer timeout that the sw watchdog (by a configurable delta), the watchdogs gets patted at the same time; if the sw wd fires it has a limited amount of time to do its action before the hw wd fires too; in this case it would also be nice to have a short ddb command for stopping hw watchdog. Each approach has its own advantages and disadvantages. The first approach guarantees that sw wd would not be interrupted by hw wd. On the other hand, there is no protection e.g. from a system getting stuck during a dump. Also, hw watchdogs would have to provide a method for emergency stop that should be safe from locking issues. The second approach is more robust. Its problems: (a) it can interrupt sw wd action too early; (b) it wastes more time if sw wd is not able to fire. Since using sw and hw watchdogs together makes more sense in unattended scenarios, I think that approach #2 may be better. IMO, attended scenarios should use sw wd exclusively. -- 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: GSoC: Semantic File System
Gabriele, Robert, Am 02.04.2009 um 19:26 schrieb Robert Watson: In the BeOS model, or my reinterpretation based on something I read a long time ago and then presumably had dreams about, the split is a bit different: the file system maintains indexes of extended attributes, which are written by applications in order to expose searchable material. For example, a mail application might write out each message as a file, and attach a series of extended attributes, such as subject line, date, author, etc. These extended attributes are then indexed automatically by the file system in order to allow queries to be evaluated. I don't recall how queries and results are expressed, and in particular, whether the queries are processed by the file system (possibly exposed via special APIs or the name space) or userspace (accessing special files maintained by the kernel that are the indexes). It's also worth observing that one of the authors of BFS was Dominic Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as part of their Spotlight project. Maybe you also might be interested that there is a PDF document (formerly book) from Dominic available describing the BeOS file system in great detail: http://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf Additionally, there seems to be a GSoC project to create something like Spotlight for Haiku, the open source BeOS clone. You could browse through the haiku-developer mailing list archives at http://www.freelists.org/archive/haiku-development , the thread where this has been discussed is titled Need Some GSoC Advice with the first mail from 21 March. Stephan ___ 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: GSoC: Semantic File System
On Tue, 7 Apr 2009, Stephan Lichtenauer wrote: Am 02.04.2009 um 19:26 schrieb Robert Watson: In the BeOS model, or my reinterpretation based on something I read a long time ago and then presumably had dreams about, the split is a bit different: the file system maintains indexes of extended attributes, which are written by applications in order to expose searchable material. For example, a mail application might write out each message as a file, and attach a series of extended attributes, such as subject line, date, author, etc. These extended attributes are then indexed automatically by the file system in order to allow queries to be evaluated. I don't recall how queries and results are expressed, and in particular, whether the queries are processed by the file system (possibly exposed via special APIs or the name space) or userspace (accessing special files maintained by the kernel that are the indexes). It's also worth observing that one of the authors of BFS was Dominic Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as part of their Spotlight project. Maybe you also might be interested that there is a PDF document (formerly book) from Dominic available describing the BeOS file system in great detail: http://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf Additionally, there seems to be a GSoC project to create something like Spotlight for Haiku, the open source BeOS clone. You could browse through the haiku-developer mailing list archives at http://www.freelists.org/archive/haiku-development, the thread where this has been discussed is titled Need Some GSoC Advice with the first mail from 21 March. Actually, I have a original copy of the book on the bookshelf behind me. :-) Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Patch for MS Hyper V (virtualization)
On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: John Baldwin wrote: On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: 2009/4/6 John Baldwin j...@freebsd.org: On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: Hmm, the problem is we need to be able to write to BARs to size them. б Any OS needs to be able to do this to know what address space regions are being decoded by devices. б We can't avoid writing to BARs. I have only vague idea what BARs are and if it's the correct diagnosis in this case, but the fact is that other operating systems (Windows, Linux tested) work, so either there is a way around it or the original premise is wrong-ish. Every OS writes to BARs to size them during boot. It's the defined procedure for sizing them. A BAR is a base address register, and it is how a PCI device gets memory and I/O port resources. OS (or BIOS) writes a starting address into the register to tell the PCI device where a given resource starts. The OS doesn't have to write to the BAR if BIOS has already done it. And the BIOS in the Hyper-V VM is obviously special, so it doesn't trip on iself. Yes it does because we don't know how _big_ the BAR is. The OS has to know if the device is decoding 1MB or 64KB because we need to reserve the entire window to prevent any other devices from using it. We don't just write the existing value, we write all 1's to it and read it back. The lower N bits stick at zero and we use that to figure out the BAR's size. See pci_add_map() in sys/dev/pci/pci.c Anyway, as far as I can tell, it's only the base register of the simulated DEC21140 device that has this issue, so it's quite possible that the bug is in that device's simulator. I've attached a modified patch that checks conservatively for this precise situation, so it should not break compatibility with anything else. I've tested it on Hyper-V. Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix relative to 7 to disable decoding via the PCI command register while sizing BARs that may address this. -- John Baldwin ___ 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: Patch for MS Hyper V (virtualization)
On Tue, Apr 7, 2009 at 9:21 AM, John Baldwin j...@freebsd.org wrote: On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: John Baldwin wrote: On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: 2009/4/6 John Baldwin j...@freebsd.org: On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: Hmm, the problem is we need to be able to write to BARs to size them. б Any OS needs to be able to do this to know what address space regions are being decoded by devices. б We can't avoid writing to BARs. I have only vague idea what BARs are and if it's the correct diagnosis in this case, but the fact is that other operating systems (Windows, Linux tested) work, so either there is a way around it or the original premise is wrong-ish. Every OS writes to BARs to size them during boot. It's the defined procedure for sizing them. A BAR is a base address register, and it is how a PCI device gets memory and I/O port resources. OS (or BIOS) writes a starting address into the register to tell the PCI device where a given resource starts. The OS doesn't have to write to the BAR if BIOS has already done it. And the BIOS in the Hyper-V VM is obviously special, so it doesn't trip on iself. Yes it does because we don't know how _big_ the BAR is. The OS has to know if the device is decoding 1MB or 64KB because we need to reserve the entire window to prevent any other devices from using it. We don't just write the existing value, we write all 1's to it and read it back. The lower N bits stick at zero and we use that to figure out the BAR's size. See pci_add_map() in sys/dev/pci/pci.c John is 100% correct. Every kernel PCI driver has to figure out how big the BAR is and IN FACT typically the BIOS assigns more address space than the register set you are mapping. This is straight out of the PCI spec. -aps ___ 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: Re: Patch for MS Hyper V (virtualization)
(Let's see if I've figured yet another workaround for the web interface= ). The address space used by the card I think is actually 0x80 bytes= , in the I/O port space. The card has it located at the port 0xEC00. Yester= day I've had all the values and addresses written to this card's registers = printed for debugging and I don't remember seeing all ones written to this = register. It was writing back first 0xEC01 (1 is the I/O space indicator), = then 0xEC00. And no, the culprit is not the missing bit 0 (which should be = read-only by the PCI spec): I've tried adding it back, and it made no diffe= rence. I'll try FreeBSD 8 and see what happens. -SB Ap= r 7, 2009 10:28:50 AM, [1]...@freebsd.org wrote: On Monday 06 April 2009 11:12:33= pm Sergey Babkin wrote: John Baldwin wrote: = On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: = 2009/4/6 John Baldwin [2]...@freebsd.org: = ; On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: = ; Hmm, the problem is we need to be able t= o write to BARs to size them. б Any OS = gt; needs to be able to do this to know what address space regions are being decoded by devices. б We can't avoid= writing to BARs. I have only vague ide= a what BARs are and if it's the correct diagnosis in this= case, but the fact is that other operating systems (Windows, = Linux tested) work, so either there is a way around it or the originalpremise is wrong-ish. Every O= S writes to BARs to size them during boot. It's the defined procedure= br for sizing them. A BAR is a base address register, and it is = how a PCI device gets memory and I/O port resources. OS (or B= IOS) writes a starting address into the register to tell the P= CI device where a given resource starts. Th= e OS doesn't have to write to the BAR if BIOS has already done it. = And the BIOS in the Hyper-V VM is obviously special, so it doesn't = trip on iself. Yes it does because we don't know how _big_ the BAR = is. The OS has to know if the device is decoding 1MB or 64KB because w= e need to reserve the entire window to prevent any other devices from u= sing it. We don't just write the existing value, we write all 1's to i= t and read it back. The lower N bits stick at zero and we use that t= o figure out the BAR's size. See pci_add_map() in sys/dev/pci/pci.c Anyway, as far as I can tell, it's only the base register of = the simulated DEC21140 device that has this issue, so it's qu= ite possible that the bug is in that device's simulator. = I've attached a modified patch that checks conservatively for this = precise situation, so it should not break compatibility with anythi= ng else. I've tested it on Hyper-V. Can you test unmodified FreeBSD = 8 on Hyper-V? It has an extra fix relative to 7 to disable decoding vi= a the PCI command register while sizing BARs that may address this. -- John Baldwin References 1. 3Dmailto:j...@freebsd.org; 2. 3Dmailto:j...@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: DNS problems
I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) Your registrar has not inserted the glue records for your name servers into the root zone. Try a different registrar. -- George Mitchell ___ 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
DNS problems
I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) ___ 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: DNS problems
Aryeh M. Friedman wrote: Already did (went a step farther had my machine at home -CURRENT use the one at work [the one with the probldem] as it's /etc/resolv.conf and as a forwarder in my named.conf and both worked fine) Forgot to mention that different ISP's so it is not a port blocking problem Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh M. Friedman wrote: I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 =k1/J -END PGP SIGNATURE- ___ 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: DNS problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh M. Friedman wrote: I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 =k1/J -END PGP SIGNATURE- ___ 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: DNS problems
Already did (went a step farther had my machine at home -CURRENT use the one at work [the one with the probldem] as it's /etc/resolv.conf and as a forwarder in my named.conf and both worked fine) Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh M. Friedman wrote: I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. - -- Xin LI delp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 =k1/J -END PGP SIGNATURE- ___ 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
KLDs missing CTF information (patch attached)
It appears that the KLD build process is missing a ctfmerge at the end, and this results in KLDs with incomplete CTF information. Here is a patch that fixes this. I verified it on amd64 with various KLDs. Before: # ctfdump /boot/kernel/if_cxgb.ko | wc -l 2269 # ctfdump /boot/kernel/zfs.ko | wc -l 430 After: # ctfdump /boot/kernel/if_cxgb.ko | wc -l 6568 # ctfdump /boot/kernel/zfs.ko | wc -l 15032 It is wasteful to have CTF information in both the .ko and the .ko.symbols file but this is what the kernel does too. Regards, Navdeep ctf-kld.patch Description: Binary data ___ 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: Patch for MS Hyper V (virtualization)
John Baldwin wrote: On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: Anyway, as far as I can tell, it's only the base register of the simulated DEC21140 device that has this issue, so it's quite possible that the bug is in that device's simulator. I've attached a modified patch that checks conservatively for this precise situation, so it should not break compatibility with anything else. I've tested it on Hyper-V. Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix relative to 7 to disable decoding via the PCI command register while sizing BARs that may address this. 8.0 (February snapshot) seems to have the same issue. I've also saved the log of writes that 7.1 does for this device: reg 10 val ec01 reg 14 val febff000 reg 18 val 0 reg 1c val 0 reg 20 val 0 reg 24 val 0 reg 30 val febe reg 4 val 117 reg 3c val b reg 3d val 1 reg 3e val 14 reg 3f val 28 reg c val 8 reg d val 40 reg 9 val 0 reg 8 val 20 reg 10 val ec00 reg 14 val febff000 reg 4 val 117 reg 4 val 117 I don't see any values. -SB ___ 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
