Re: [Fwd: i-Buddie 4: Synaptics touch pad FreeBSD support?]
On Fri, 2002-09-27 at 16:54, Guido Van Hoecke wrote: > The windoze driver offers a set of extra features which I found useful > and which I would appreciate on a FreeBSD box: > - configurable touch behaviour > - edge motion > - scrolling > - button actions (including virtual btns supplied by the 4 corners) > I'm very willing to supply more info on these features. > > I have no idea whether any of these are supplied by the tpconfig stuff. > The only feature I found any mention of in that package, is the ability > to disable the 'tap to click'. But maybe that is just a lack of > documentation. None of those features are possible without putting the device in absolute mode :( I should just get off my lazy ass and get it to work :) If anyone is interested the specs are readily available from the synaptics web site. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk space over 1 TB
Hello, > The i386 port uses the generic disklabel code, which has 32 bit logical > block addressing, which means that the partitions themselves are limited > to 1TB or so. Will this change or GEOM will be the standard method? (and thanks, I forgot that all of this is on IA-32) > But one could theoretically use a 64 bit EFI layout on a large external > raid and boot from a smaller disk. I don't want to boot from the array, so this could be a solution. Will this have any drawbacks comparing to the usual way (for example stability, speed)? Is it in production use somewhere? Could you please give me some pointers on this topic? (some kind of how-to about the usage of this stuff, there isn't much about it, just the manpage. Where could I find the userland part?) Thanks, --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Disk space over 1 TB
In message <[EMAIL PROTECTED]>, Attila Na gy writes: >Hello, > >> The i386 port uses the generic disklabel code, which has 32 bit logical >> block addressing, which means that the partitions themselves are limited >> to 1TB or so. >Will this change or GEOM will be the standard method? (and thanks, I >forgot that all of this is on IA-32) I will not change the disklabel format, so as such that will not change. It should be noted that a larger sectorsize can be used in the disklabel data, and thus it would be trivial to extend the life for disklabel a little bit. Geom will deal with all I/O requests as 64 bit byte offsets, so as such GEOM will solve the problem, and provided the disk-driver authors follow suit, this entire thing can be fixed before 5.0. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Just a wild idea
Sorry for the late reply (I don't skim through the hackers list very often). Paul Schenkeveld <[EMAIL PROTECTED]> wrote: > For many applications however, for example lpd, named, sendmail, > tac_plus and others, it would be more than good enough to run that > program as a normal, non-root user provided there is a way to bind > to that single low TCP and/or UDP port that the program needs access > to. I haven't actually tried this, but shouldn't it be possible to use IPFW's forwarding feature for that? For example, let sendmail run on port 2500 and then add ipfw fwd rules to forward between ports 2500 and 25. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Maybe it's time to commit parts of S/390 port?
Hi! Just want to let your know I can send some patches to be committed to -current. Anyone interested? I'am asking because I tried to communicate with some FreeBSD people this week, but their did't respond for unknown reason (busy?). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Maybe it's time to commit parts of S/390 port?
In message <[EMAIL PROTECTED]>, "Serguei Tzukanov" writes: >Hi! > >Just want to let your know I can send some patches to be committed >to -current. Anyone interested? I'am asking because I tried >to communicate with some FreeBSD people this week, but their >did't respond for unknown reason (busy?). Hey easy now :-) I'm discussing the issue with core@ right now, and if they agree that this should go in the tree, I'll be your designated committer for the first period of time. Stay tuned, I'll get back to you when core@ gives me their conclusion. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IBM ATA Deskstars *without* tagged queueing?
On Thu, Sep 26, 2002 at 08:07:27PM +0200, Hellmuth Michaelis wrote: > Exactly the same thing happened here with a IC35L020AVER07-0; it did not > do tagging and i bought it (and many other IBM drives) because of that. [snip] > It turned out that the drive i bought had DELL firmware in it [ :- ] > so they sent me an updated DELL firmware, but that did not enable tagged > support. I asked for a cross update program to get IBM firmware; they > had none. They wrote one :-), i got it and now my drive does tagged > command queueing. > > And all this for a dirt cheap drive ... This is exactly the sort of thing I'd suspected. If you look at that article (URL in previous post) then as you can see they've significantly changed the manufacturing process (even made at a different plant). Are there any shortcuts to dealing with IBM OEM support or any aspects of their process? It would be helpful to know before I start the same dialogue with them re: my DeskStar 120GXP. If you could send myself as well as Soren a copy of the firmware you received in the end, too, that would be great. :-) Many thanks for unraveling this mystery! BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Runlevels and opcodes
Runlevels and opcodes I am a bit familiar with the design of operating systems but i definitely lack practical experience so please apologize if i am confusing things ... Anyway i think the subject is likely to interest our readers ! On most modern operating systems, system calls provide control and isolation for resource access (memory, drivers...) and thereby security. *** But what does prevent a user-level process from executing wild instructions (RESET, traps, other dangerous instructions and undocumented features) ? More generally, does any of you know if some architectures provide the possibility of designing custom transitions between processor "runlevels" (usually there are only 2 available, superuser and user modes) ? E.g. processor starts in super-user mode > thread 1: switch to user-level with some opcodes masked > thread 2: switch to another user-level with other opcodes masked How do context switches occur on existing architectures ? Is it some kind of "forking" from super-user mode to user mode and multiple simultaneous user mode contexts (no switching back to super-user mode) ? Basically, what are the main differences between (intel, sparc, alpha, ...) from this point of view ? Best regards Phil To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-23 13:08:04 -0400:
> The odd behavior of variables is only one item from a whole list of them.
> Go take a look at what use: means, if you want a headache.
you mean .USE? looks quite powerful... a can of worms if misused. :)
> Or, how about the behavior of "include", which *does* work, even
> though the man page says that only ".include" will work ("include" is
> compatible with both BSD make and GNU make, an important point.)
yup. or the fact that /usr/share/doc/psd/12.make/paper.ascii.gz
documents conditionals in the form #keyword instead of .keyword
(that might work, i haven't tried, but shouldn't the tutorial be
updated? even if the # forms work they surely look deprecated from
the fact that i haven't seen a single use in the system makefiles)
hm, i don't think i made myself clear with the previous para. how
about this: is the pmake tutorial mentioned above carved in stone or
are updates allowed? if it's immutable, is derivative work
permitted? i'm thinking about basically rewriting the tutorial in
docbook (i have /usr/ports/docproj installed), fixing at least the
issues *i* have with the material.
what do you think?
> When you don't have any problem with a file like bsd.port.mk, then you'll
> be able to claim to know make.
BTW, this reminds me: I think there is a bug in
/usr/ports/Mk/bsd.port.mk. I'll send a separate message.
--
begin 666 nonexistent.vbs
FreeBSD 4.7-RC
7:12PM up 10 days, 2:27, 13 users, load averages: 0.04, 0.03, 0.00
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyname_r() fbsd equiv?
On Fri, Sep 13, 2002 at 09:01:45AM -0700, Terry Lambert wrote the words in effect of: > Terry Lambert wrote: > > Jev wrote: > > > Im trying to build some software on freebsd, which wants to use > > > the thread safe gethostbyname_r(). Despite having very bad C skills im > > > going to attempt to patch it. What would I use in place of > > > gethostbyname_r() on freebsd? > > > > Do you need the real gethostbyname_r(), or do you need the > > bastardized Linux version? The real version has the prototype: > > In case anyone cares, it's the pre-knowing the buffer size, with > no ability to return partial results and at the same time indicate > the buffer is to short, and the h_errno pointer and the return > of the hostent structure whose address was passed, rather than an > int, that I object to in the Linux interface. > > And yes, I know it matches the Solaris interface. Aplogies, for the late arrival of this mail. I do not read -hackers very much these days. But I found this worth the while to comment. Doesnt getaddrinfo() do whatever gethostbyname() can do? And also, if my source of information is correct, getaddrinfo() should be thread-safe and also, it is under the POSIX p1003.1g. Regards. -- Hiten Pandya http://www.unixdaemons.com/~hiten [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4.6.2/RELENG_4: timeout in wi_seek and wi_cmd
On a machine with either 4.6.2 of RELENG_4 as of today with: 3x wiX: mem 0xfedf8000-0xfedf8fff irq 11 at device 19.X on pci0 wiX: 802.11 address: 00:06:25:a7:a7:2a wiX: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wiX: Intersil Firmware: Primary 1.00.05, Station 1.03.04 I am getting regular errors like: wi1: timeout in wi_cmd 0x010b; event status 0x8000 and at timesL wi0: timeout in wi_seek to 146/3c; last status 403c when doing repeated/contineous HTTP fetches of large file for a few hours (at around 1-2Mbit, 1Gbyte or bigger) across just one interface (i.e. we're not bridging or routing - but sending internal to /dev/null). Lots of short/quick small files does not seem to trip the above. And in particular once the latter starts happenig - it seems to get gradually worse / interspeced with 0.5 -2 seconds hangs of all traffic on all interfaces. RELENG_4 seems to be slightly less of an issue than 4.6.2 - but no fundamental changes/differences seen. Is this firmware related ? is WI_TIMEOUT timeout soo long that it causes other things to fail ? Any way to stop the 'hangs' from hitting other interfaces. Or any other hints/insights ? Note that we did have to increase mbuff sizes to 4096 to quell mbuff errors/warnings. Ta! Dw To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Security of a JAIL UDP patch
U, named currently does work within a jail ... I run several at the
moment ...
On Thu, 26 Sep 2002, Martin Matuska wrote:
> I would like to ask which aspects has this patch on security of a jailed
> environment.
> This patch enables the use of named or ircd in jails.
>
> --- in_pcb.c.old Mon Mar 18 23:57:57 2002
> +++ in_pcb.c Tue Mar 19 09:52:45 2002
> @@ -501,6 +501,8 @@
> int error;
>
> if (inp->inp_laddr.s_addr == INADDR_ANY && p->p_prison != NULL) {
> + if (inp->inp_lport != 0)
> + inp->inp_laddr.s_addr = htonl(p->p_prison->pr_ip);
> bzero(&sa, sizeof (sa));
> sa.sin_addr.s_addr = htonl(p->p_prison->pr_ip);
> sa.sin_len=sizeof (sa);
>
> Patch author was Lamont Granquist [EMAIL PROTECTED]
> Reference:
> http://www.freebsd.org/cgi/getmsg.cgi?fetch=393634+395986+/usr/local/www/db/
> text/2002/freebsd-stable/20020331.freebsd-stable
>
> Thank you very much
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
kernel panic in 4.5-STABLE
I've been experiencing somewhat periodic panics on my 4.5-STABLE box:
[root@wickerpark crash] # uname -a
FreeBSD wickerpark.cnt.org 4.5-STABLE FreeBSD 4.5-STABLE #0: Thu Aug 29
12:26:05 CDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WP-DEBUG i386
kgdb output follows:
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at phsyical address 0x00472000
initial pcb at physical address 0x003b9120
panicstr: page fault
panic messages:
---
Fatal trap 19: non-maskable interrupt trap while in kernel mode
instruction pointer = 0x8:0xc02a9304
stack pointer = 0x10:0xc03833dc
frame pointer = 0x10:0xc03833e8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, IOPL = 0
current process = Idle
interrupt mask = net tty
trap number = 19
panic: non-maskable interrupt trap
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x30
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02c53c0
stack pointer = 0x10:0xc038322c
frame pointer = 0x10:0xc0383234
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = net tty bio
trap number = 12
panic: page fault
Uptime: 7d21h6m32s
dumping to dev #da/0x20001, offset 1572864
dump 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241
240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223
222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205
204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187
186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169
168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151
150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133
132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115
114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96
95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72
7170 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48
47 46 45 44 43 42 4140 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 1110 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc01d93db in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:316
#2 0xc01d9819 in panic (fmt=0xc037ac2c "%s") at
/usr/src/sys/kern/kern_shutdown.c:595
#3 0xc030eea7 in trap_fatal (frame=0xc03831ec, eva=48)
at /usr/src/sys/i386/i386/trap.c:966
#4 0xc030eb55 in trap_pfault (frame=0xc03831ec, usermode=0, eva=48)
at /usr/src/sys/i386/i386/trap.c:859
#5 0xc030e6fb in trap (frame={tf_fs = -1070071792, tf_es = 16, tf_ds =
16,
tf_edi = -1069733184, tf_esi = 0, tf_ebp = -1070058956, tf_isp =
-1070058984,
tf_ebx = -1069915716, tf_edx = 6864960, tf_ecx = 2, tf_eax = 0,
tf_trapno = 12,
tf_err = 0, tf_eip = -1070836800, tf_cs = 8, tf_eflags = 66054,
tf_esp = 0,
tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:458
#6 0xc02c53c0 in acquire_lock (lk=0xc03a61bc) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:266
#7 0xc02c99e2 in softdep_fsync_mountdev (vp=0xcd4cb3c0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:4024
#8 0xc02cdcea in ffs_fsync (ap=0xc03832a8) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:134
#9 0xc02cc9ab in ffs_sync (mp=0xc1668e00, waitfor=2, cred=0xc0e3c680,
p=0xc03d2ac0)
at vnode_if.h:558
#10 0xc0208f03 in sync (p=0xc03d2ac0, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:576
#11 0xc01d9176 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:235
#12 0xc01d9819 in panic (fmt=0xc037ac2c "%s") at
/usr/src/sys/kern/kern_shutdown.c:595
#13 0xc030eea7 in trap_fatal (frame=0xc038339c, eva=0)
at /usr/src/sys/i386/i386/trap.c:966
#14 0xc030e88a in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1050948736,
tf_esi = -1050910720, tf_ebp = -1070058520, tf_isp = -1070058552,
tf_ebx = -1050910720, tf_edx = 10240, tf_ecx = 0, tf_eax = 4097,
tf_trapno = 19,
tf_err = 0, tf_eip = -1070951676, tf_cs = 8, tf_eflags = 582,
tf_esp = -1050910720, tf_ss = -1050910720}) at
/usr/src/sys/i386/i386/trap.c:628
#15 0xc02a9304 in dc_reset (sc=0xc15c6000) at machine/cpufunc.h:334
#16 0xc02ab693 in dc_init (xsc=0xc15c6000) at
/usr/src/sys/pci/if_dc.c:3004
#17 0xc02aa92d in dc_rxeof (sc=0xc15c6000) at
/usr/src/sys/pci/if_dc.c:2401
#18 0xc02ab00f in dc_intr (arg=0xc15c6000) at
/usr/src/sys/pci/if_dc.c:2776
--
Paul Smith <[EMAIL PROTECTED]>
Center for Neighborhood Technology
Chicago, IL USA
To Unsubscribe: se
Re: Runlevels and opcodes
On Fri, 2002-09-27 at 11:47, [EMAIL PROTECTED] wrote: > *** But what does prevent a user-level process from executing > wild instructions (RESET, traps, other dangerous instructions > and undocumented features) ? I'm probably less knowledgeable then you are but in protected-mode programming isn't the kernel responsible for making sure no programs go rogue? -- Ryan "leadZERO" Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Runlevels and opcodes
On 27 Sep 2002, Ryan Sommers wrote: > > *** But what does prevent a user-level process from executing > > wild instructions (RESET, traps, other dangerous instructions > > and undocumented features) ? > > I'm probably less knowledgeable then you are but in protected-mode > programming isn't the kernel responsible for making sure no programs go > rogue? in some ways, but "wild instructions" are the province of the architecture. You can't execute them in user mode. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
