Re: Clang now builds world and kernel, on i386 and amd64
On Sat, Sep 25, 2010 at 08:55:51PM +, b. f. wrote: Dmitry Andric wrote: On 2010-09-25 21:16, Paul B Mahol wrote: When to expect to get rid of GNU as and other binutils tools? Work is progressing steadily on the clang/llvm integrated assembler, which removes the need for an external assembler such as gas, and which should also reduce compile times further. This is really in alpha state right now, but Roman Divacky (who is one of the active contributors) can probably tell more about its progress. Another important component is of course the linker, but I am not aware of a similar project to replace that; excepting gold, but that is a GPLv3 project too, unfortunately. There has been another effort underway for some time: http://sourceforge.net/apps/trac/elftoolchain/ Perhaps some coordination between those working on llvm in FreeBSD, and the elftoolchain project, would be helpful? there's not that much overlap between those two - in a case elftoolchain gets to implementing linker it would be sweet if it supported the same plugin API as gold so we can use LLVM LTO plugin there... beside that I dont see much point in teaching nm to see into llvm object files etc. (we already have tools for that) ___ 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: DHCP server in base
2010/9/25 Marcin Cieslak sa...@saper.info: M. Warner Losh i...@bsdimp.com wrote: : I agree but like Aleksandr said, almost 70% of dhcp code is already in : base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea : to keep some parts in the ports tree and move out from the base. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. As a road-warrior consultant I really value having things like bootpd, tftpd, bootparamd and similar software always there. Many times I wished dhcpd was there, too. Another typical use - FreeBSD makes a good small network router out of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing). I am not sure about the whole modularization goal - I think the relatively monolythic nature is one of the FreeBSD's merits. For example, it's good to have NFSv4, Kerberos and required userland daemons packaged in the base. I don't want to have those done separately in a modular way (although Heimdal we have is older then what their current trunk is). We got stuck on connecting Linux boxes via NFSv4 to Solaris and BSD because one of the userland modules in Linux was terribly out of date and authenticating the user w/Kerberos was not possible. As we build a more complex networking landscape with VIMAGE and friends I think that the benefits of better integration of dhcpd in the base system (rc.d, rc.conf...) may outweigh its costs (maintenance, bloat, etc.). //Marcin ___ 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 I agree that for some people it will be completely useless, but if we can disable it in src.conf everyone will be happy. Since FreeBSD is great for a router it's really fast to make a full working server without installing anything else. I agree for the 70% part of dhcp which is already present. In any case, src.conf(5) is still working and usable, isn't it? Kind regards, -- Demelier David ___ 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: Recent GELI additions.
Hi, Thanks a lot for your efforts, Pawel! Geli is definitely awesome. Bye, Olivier Certner ___ 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: DHCP server in base
David DEMELIER said: I agree that for some people it will be completely useless, but if we can disable it in src.conf everyone will be happy. Since FreeBSD is great for a router it's really fast to make a full working server without installing anything else. What is the problem of installing something else? You are probably ignoring that many people are complaining about the presence of sendmail, bind, perl etc. in the base system from ages, indeed X and perl have been removed, and it is clear that the consensus is to make the base smaller not bigger. And frankly i have *very* hard time to think that a DHCP server in the base has any utility. why not maxima for example? I am interested in formal computation, you are interested in routers, another one likes images and would want gimp, and so on. -- Michel TALON ___ 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: Clang now builds world and kernel, on i386 and amd64
W dniu 2010-09-24 16:34, Dimitry Andric pisze: On 2010-09-24 14:13, Bartosz Stec wrote: Could you please try to rename this make.conf to e.g. make.conf.disable, and retry the world build? Still the same without make.conf. My personal guess is, that clang builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by GCC with exactly the same make.conf has no problems with world building :) I still cannot reproduce your issue... To check, I have built world with CPUTYPE=athlon-xp, verified it used -O2 -pipe -march=athlon-xp as compilation flags for the world stage, and installed the resulting clang executables. Those clang executables do not exhibit the same problem as yours do; they can build tblgen (during the bootstrap-tools stage) fine. I suggest you comment out the CPUTYPE macro in make.conf for now, rebuild your world with gcc, and then rebuild it with clang again, to see if the issue goes away. Indeed, I was right. Problem is gone after hashing out CPUTYPE line, building world with GCC, and with clang after that. Now world is building without problems. But hey, i just realized that: # dmesg | grep -i cpu CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) I simply forgot that about a year ago I changed Athlon XP in this BOX to Athlon MP and I didn't changed CPUTYPE in make.conf... So maybe clang in fact did exactly what it should and created binary designed to other CPUTYPE ;) I don't know exact differences between Athlon XP/MP architecture (registers specially) but I just started another try with CPUTYPE=Athlon-mp and I will post results :) -- Bartosz Stec -- IT4Pro Bartosz Stec http://www.it4pro.pl tel: 607041002 E-Mail: bartosz.s...@it4pro.pl ___ 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: Clang now builds world and kernel, on i386 and amd64
W dniu 2010-09-26 14:42, Erik Trulsson pisze: On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote: W dniu 2010-09-24 16:34, Dimitry Andric pisze: On 2010-09-24 14:13, Bartosz Stec wrote: Could you please try to rename this make.conf to e.g. make.conf.disable, and retry the world build? Still the same without make.conf. My personal guess is, that clang builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by GCC with exactly the same make.conf has no problems with world building :) I still cannot reproduce your issue... To check, I have built world with CPUTYPE=athlon-xp, verified it used -O2 -pipe -march=athlon-xp as compilation flags for the world stage, and installed the resulting clang executables. Those clang executables do not exhibit the same problem as yours do; they can build tblgen (during the bootstrap-tools stage) fine. I suggest you comment out the CPUTYPE macro in make.conf for now, rebuild your world with gcc, and then rebuild it with clang again, to see if the issue goes away. Indeed, I was right. Problem is gone after hashing out CPUTYPE line, building world with GCC, and with clang after that. Now world is building without problems. But hey, i just realized that: # dmesg | grep -i cpu CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) I simply forgot that about a year ago I changed Athlon XP in this BOX to Athlon MP and I didn't changed CPUTYPE in make.conf... So maybe clang in fact did exactly what it should and created binary designed to other CPUTYPE ;) I don't know exact differences between Athlon XP/MP architecture (registers specially) but I just started another try with CPUTYPE=Athlon-mp and I will post results :) The only difference between Athlon XP and Athlon MP is that the MP variants are certified for multi-processor use (in reality most Athlon XP also worked just fine in multi-processor systems, or could easily be modified to do so.) Available instructions and registers are identical between the two. Mobile variants of the Athlon XP should also be identical from a programming point of view. That's what I thought too, but in that case, why are they different optimisations available? In /usr/share/examples/etc/make.conf: # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 Or maybe some of them are in fact bywords to compiler? Still, my CURRENT box is at idle mostly, so I will experiment a little and see what I get. Cheers -- Bartosz Stec ___ 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: Clang now builds world and kernel, on i386 and amd64
On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote: W dniu 2010-09-24 16:34, Dimitry Andric pisze: On 2010-09-24 14:13, Bartosz Stec wrote: Could you please try to rename this make.conf to e.g. make.conf.disable, and retry the world build? Still the same without make.conf. My personal guess is, that clang builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by GCC with exactly the same make.conf has no problems with world building :) I still cannot reproduce your issue... To check, I have built world with CPUTYPE=athlon-xp, verified it used -O2 -pipe -march=athlon-xp as compilation flags for the world stage, and installed the resulting clang executables. Those clang executables do not exhibit the same problem as yours do; they can build tblgen (during the bootstrap-tools stage) fine. I suggest you comment out the CPUTYPE macro in make.conf for now, rebuild your world with gcc, and then rebuild it with clang again, to see if the issue goes away. Indeed, I was right. Problem is gone after hashing out CPUTYPE line, building world with GCC, and with clang after that. Now world is building without problems. But hey, i just realized that: # dmesg | grep -i cpu CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) I simply forgot that about a year ago I changed Athlon XP in this BOX to Athlon MP and I didn't changed CPUTYPE in make.conf... So maybe clang in fact did exactly what it should and created binary designed to other CPUTYPE ;) I don't know exact differences between Athlon XP/MP architecture (registers specially) but I just started another try with CPUTYPE=Athlon-mp and I will post results :) The only difference between Athlon XP and Athlon MP is that the MP variants are certified for multi-processor use (in reality most Athlon XP also worked just fine in multi-processor systems, or could easily be modified to do so.) Available instructions and registers are identical between the two. Mobile variants of the Athlon XP should also be identical from a programming point of view. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: Clang now builds world and kernel, on i386 and amd64
W dniu 2010-09-26 14:54, Bartosz Stec pisze: W dniu 2010-09-26 14:42, Erik Trulsson pisze: On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote: W dniu 2010-09-24 16:34, Dimitry Andric pisze: On 2010-09-24 14:13, Bartosz Stec wrote: Could you please try to rename this make.conf to e.g. make.conf.disable, and retry the world build? Still the same without make.conf. My personal guess is, that clang builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by GCC with exactly the same make.conf has no problems with world building :) I still cannot reproduce your issue... To check, I have built world with CPUTYPE=athlon-xp, verified it used -O2 -pipe -march=athlon-xp as compilation flags for the world stage, and installed the resulting clang executables. Those clang executables do not exhibit the same problem as yours do; they can build tblgen (during the bootstrap-tools stage) fine. I suggest you comment out the CPUTYPE macro in make.conf for now, rebuild your world with gcc, and then rebuild it with clang again, to see if the issue goes away. Indeed, I was right. Problem is gone after hashing out CPUTYPE line, building world with GCC, and with clang after that. Now world is building without problems. But hey, i just realized that: # dmesg | grep -i cpu CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) I simply forgot that about a year ago I changed Athlon XP in this BOX to Athlon MP and I didn't changed CPUTYPE in make.conf... So maybe clang in fact did exactly what it should and created binary designed to other CPUTYPE ;) I don't know exact differences between Athlon XP/MP architecture (registers specially) but I just started another try with CPUTYPE=Athlon-mp and I will post results :) The only difference between Athlon XP and Athlon MP is that the MP variants are certified for multi-processor use (in reality most Athlon XP also worked just fine in multi-processor systems, or could easily be modified to do so.) Available instructions and registers are identical between the two. Mobile variants of the Athlon XP should also be identical from a programming point of view. That's what I thought too, but in that case, why are they different optimisations available? In /usr/share/examples/etc/make.conf: # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 Or maybe some of them are in fact bywords to compiler? Still, my CURRENT box is at idle mostly, so I will experiment a little and see what I get. Cheers Argh, I assumed that 'Mobile Athlon XP' == 'Athlon MP' while it seem's that they aren't. CPUTYPE=athlon-xp was a right choice for my CPU. Sorry for mistake. -- Bartosz Stec ___ 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
psm(4) - synaptics touch pad strange behavier
Hi psm(4) masters! I have trouble using Synaptics TouchPad, psm(4) on my CF-R9. The trouble is that the mouse cursor moves at random, and the mouse button is clicked without button action. I heard same trouble from ume@'s CF-R8. So I enabled options PSM_DEBUG=5 and traced psm's packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : FreeBSD 9.0-CURRENT #39: Sun Sep 26 22:07:37 JST 2010 n...@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64 : atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: PS/2 mouse port irq 12 on acpi0 psm0: current command byte:0065 Synaptics Touchpad v6.2 Model information: infoRot180: 0 infoPortrait: 0 infoSensor: 57 infoHardware: 80 infoNewAbs: 1 capPen: 0 infoSimplC: 1 infoGeometry: 2 Extended capabilities: capExtended: 1 capPassthrough: 0 capSleep: 1 capFourButtons: 0 capMultiFinger: 0 capPalmDetect: 1 Additional Buttons: 0 psm0: found Synaptics Touchpad psm0: PS/2 Mouse flags 0x3000 irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons psm0: config:7000, flags:0008, packet size:6 psm0: syncmask:c0, syncbits:00 : atkbdc: atkbdc0 already exists; skipping it : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * service moused onestart - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 3b 47 c1 ~~ ~~ required, OK! synaptics signature, OK! psm: ENABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 01 64 ~~ ~~ bad.. synaptics signature, NG! psm0: lost interrupt? psm0: lost interrupt? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * touch to panel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - psmintr: 4a d0 ba 1e 90 d0 ~~ ~~ 0xc0 must be 0xc0 0xc8 must be 0x80 These are NG. psmintr: Sync bytes now 00c0,00c0 ~ So mismatch! psmintr: bd 1d 90 be 1a 90 psmintr: out of sync (0080 != 0040) 1 cmds since last error. psmintr: discard a byte (1) psmintr: 1d 90 be 1a 90 59 psmintr: out of sync ( != 0040) 0 cmds since last error. psmintr: discard a byte (2) psmintr: 90 be 1a 90 59 d0 psmintr: out of sync (0080 != 0040) 0 cmds since last error. psmintr: discard a byte (3) psmintr: be 1a 90 59 d0 c1 psmintr: out of sync (0080 != 0040) 0 cmds since last error. psmintr: discard a byte (4) psmintr: 1a 90 59 d0 c1 19 psmintr: out of sync ( != 0040) 0 cmds since last error. psmintr: discard a byte (5) psmintr: 90 59 d0 c1 19 90 psmintr: out of sync (0080 != 0040) 0 cmds since last error. * Data is discarded, so broken data into proc_synaptics(). psmintr: re-enable the mouse. psm: DISABLE_DEV return code:00fa psm: ENABLE_DEV return code:00fa psmintr: 5c d0 ba 5d d0 aa psmintr: 7c 03 90 3c e7 90 psmintr: cf 6b c0 cf 71 c0 psmintr: out of sync (00c0 != 0040) 0 cmds since last error. psmintr: reset the mouse. psm0: current command byte: 0047 (reinitialize). psm: DISABLE_DEV return code:00fa kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID: psm: ENABLE_DEV return code:00fa psm: DISABLE_DEV return code:00fa psm: SET_RESOLUTION (3) 00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 03 64 ~~ ~~ bad.. synaptics signature, NG! psm: SET_RESOLUTION (3) 00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 03 64 ~~ ~~ bad.. synaptics signature, NG! psm: SET_SCALING11 return code:00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (3) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (3) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_RESOLUTION (3) 00fa psm: SEND_AUX_DEV_DATA return code:00fa psm: data 08 00 00 psm: SET_SAMPLING_RATE (200) 00fa psm: SET_SAMPLING_RATE (100) 00fa psm: SET_SAMPLING_RATE (80) 00fa psm: SEND_DEV_ID return code:00fa
Re: Recent GELI additions.
Indeed, truly impressive work. geli makes encryption a bliss :) Thank you very much p...@! On 9/25/10, Pawel Jakub Dawidek p...@freebsd.org wrote: Hi. I'd like to inform about three new features in GELI available in HEAD: 1. AES-XTS encryption. XTS mode is a standard that is recommended these days for storage encryption. This is the default now. AES-XTS support was also added to opencrypto framework and aesni(4) driver. 2. Multiple encryption keys. GELI will use one encryption key for at most 2^20 blocks (sectors), as it is not recommended to use the same encryption key for too much data. It generates keys array from the master key on attach and uses it accordingly. This is the default now. 3. Passphrase can now be loaded from a file (-J and -j options). -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! ___ 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: CFR: Replace man/manpath/whatis/apropos with a shell script
On Sat Sep 11 10, Gordon Tetlow wrote: On Thu, Sep 9, 2010 at 7:41 PM, Alexander Best arun...@freebsd.org wrote: Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages would be appreciated. I'm new to manpage authoring and could use a review. you forgot the AUTHORS section in all of the man pages. ;) it's always nice to see who wrote the code by reading the man pages and not having to look at the source itself imho. It felt weird to promote myself like that. I might add it. There is certainly precedent for either way. any news on when your work will hit HEAD? cheers. alex Gordon -- 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: psm(4) - synaptics touch pad strange behavier
On Sun, Sep 26, 2010 at 11:44 AM, Norikatsu Shigemura n...@freebsd.org wrote:
Hi psm(4) masters!
I have trouble using Synaptics TouchPad, psm(4) on my CF-R9.
The trouble is that the mouse cursor moves at random, and the
mouse button is clicked without button action. I heard same
trouble from ume@'s CF-R8.
So I enabled options PSM_DEBUG=5 and traced psm's packets.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
:
FreeBSD 9.0-CURRENT #39: Sun Sep 26 22:07:37 JST 2010
n...@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64
:
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0065
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d
ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67
atkbd0: [GIANT-LOCKED]
psm0: unable to allocate IRQ
psmcpnp0: PS/2 mouse port irq 12 on acpi0
psm0: current command byte:0065
Synaptics Touchpad v6.2
Model information:
infoRot180: 0
infoPortrait: 0
infoSensor: 57
infoHardware: 80
infoNewAbs: 1
capPen: 0
infoSimplC: 1
infoGeometry: 2
Extended capabilities:
capExtended: 1
capPassthrough: 0
capSleep: 1
capFourButtons: 0
capMultiFinger: 0
capPalmDetect: 1
Additional Buttons: 0
psm0: found Synaptics Touchpad
psm0: PS/2 Mouse flags 0x3000 irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68
psm0: [GIANT-LOCKED]
psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons
psm0: config:7000, flags:0008, packet size:6
psm0: syncmask:c0, syncbits:00
:
atkbdc: atkbdc0 already exists; skipping it
:
snipped for brevity
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
I read Synaptics's Synaptics PS/2 TouchPad Interfacing Guide,
PN: 511-000275-01 Rev.A and sys/dev/atkbdc/psm.c. Accordingly
these, I think no problem about implementing synaptics processing
part, maybe.
But read_aux_data_no_wait is really OK? Accordingly, my dumped
data pointed out 'not synaptics data.'. Some initialization is
required? I didn't know what.
psmintr() in sys/dev/atkbdc/psm.c
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
To fix this issue, should I do other?
I have not looked at this code in a while, but I seem to remember
having some problems when attempting to use the Synaptics extended
support in psm(4). I'm not certain if you are running with or
without the loader tunable enabled for extended and/or a custom
device.hints. Snippet from psm(4) man page
LOADER TUNABLES
Extended support for Synaptics touchpads can be enabled by setting
hw.psm.synaptics_support to 1 at boot-time. This will enable psm to han-
dle packets from guest devices (sticks) and extra buttons.
Tap and drag gestures can be disabled by setting hw.psm.tap_enabled to 0
at boot-time. Currently, this is only supported on Synaptics touchpads
with Extended support disabled. The behaviour may be changed after boot
by setting the sysctl with the same name and by restarting moused(8)
using /etc/rc.d/moused.
There is also some additional documentation for the extended support
here: http://wiki.freebsd.org/SynapticsTouchpad
The last I looked, I was successfully using synaptics touchpad with
the loader tunables hw.psm.synaptics_support set to 0, and
hw.psm.tap_enabled set to 0 (at least on my Dell 1520), so that the
touchpad would just work like a normal mouse. I seem to remember a
few pr's (84411) against psm synaptics support for your issue as well
(including a potential patch), but best to check with some recent
deveopers in this area. (Perhaps philip@ and/or dumbbell@ could chime
in ?)
Good Luck.
-_Dave
___
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
netisr software flowid
Hi.
What is the status for software flowid calculation? I found the old netisr2
patch[1] from Robert Watson and took from there code for setting flowid in
tcp_input with some changes[2]. It work for me very well (8.1-stable) - now the
server can handle not transit traffic without drops up to 118Kpps 60MB/s
incoming and up to 107Kpps 50MB/s outgoing, netisr dispatch packets via three
threads by round-robin:
12 root -44- 0K 336K CPU22 18:43 56.15% {swi1: netisr 2}
12 root -44- 0K 336K RUN 3 18:41 54.49% {swi1: netisr 3}
12 root -44- 0K 336K CPU00 18:39 50.39% {swi1: netisr 0}
12 root -68- 0K 336K WAIT1 8:01 18.07% {irq256: bge0}
So, what the reason to exclude this code from final version?
[1] http://www.watson.org/~robert/freebsd/netperf/20090523-netisr2.diff
[2] http://gate.kliksys.ru/~ai/software_flowid.diff
___
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
Parallelized scripting
Hi, I just wrote a rough C program that may help to do parallelized scripting, for example, parallelized rc.d scripts. http://github.com/buganini/brackets in this way it is easy to use, no need to escape argv for multiple times. any comments are welcomed. 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
-current under Xen
After bruce C gave me the hint of kern.eventtimer.periodic=1, I was able to boot -current on my vps at rootbsd.com, but it hangs on reboot.. some time before the unmounts as the file systems need to be cleaned on the next successful boot. Has anyone had any experience with this? unfortunately I can't yet tell you the version of Xen in use there. ___ 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
ATI Radeon HD 3200 / HP Laptop (Using)
I see that the Radeon HD 3200 needs r600_dri.so On the mailing list I saw on Dec 5, 2009 there was a patch here: http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058115.html Can anyone confirm that this was ever committed to FreeBSD Head and MFC;d 8.1 I cant get my 3D acceleration to work in KDE4 Cheerio! Michael -- Thanks, Michael Rusch rus...@gmail.com twitter - @weeddude ___ 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
