Re: Re: How can process in STOP state consume 200% CPU?
Jun 28, 2011 04:29:35 PM, jh...@dataix.net wrote: >> I got Vir= tualBox process in a strange state. It has the status STOP but >>= shows by top as consuming 200% CPU for a very long time. >> How i= s this possible and what does this mean? Process time stays at 0:00 >= ;> TIME. kill -9 doesn't kill it. > > >I would suppose= that because you stopped the clients frontend that the >backend has = not been notified and is doing its best to draw to the >screen causin= g a high CPU usage. (Sorry about quoting, it doesn't always work wel= l from the web client). Most probably the process is running in an endle= ss loop in the kernel mode. Where it got after entering the STOP state. = Remember, the signals are processed only after the process exits from th= e kernel mode to the user mode, and so are the scheduling states. While = it's in the kernel mode, you can't do anything to it other than use the = kernel debugger. -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"
Re: Re: coherence-problem on the mapped memory buffer
Jul 29, 2010 12:58:07 PM, a...@icyb.net.ua wrote: >on 29/07/2010 19:13 Andriy Gapon said the following: >> on 29/07/2010 17:13 Alexander Fiveg said the following: >In fact I have a suspicion that the problem might have to do with multiple >mappings of the shared pages, but far from sure... >Take a look at Intel® 64 and IA-32 Architectures Software Developer’s Manual >Volume 3A - System Programming Guide, Part 1; Chapter 11.12.4 Programming the >PAT; >starting at the following words: >«The PAT allows any memory type to be specified in the page tables, and >therefore >it is possible to have a single physical page mapped to two or more different >linear addresses, each with different memory types. Intel does not support this >practice...» My guess would be that the memory type is not marked as DMA-capable. AFAIK the Intel CPUs do the hardware snooping on the physical addresses, so they have no coherency issues benween themselves. However if a DMA writer changes the memory, this I think does not get normally propagated to the front-side bus, and the CPUs would not see it. You may need to either explicitly flush the CPU cache before accessing these pages or mark them as non-cacheable. -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"
Re: TCP over UDP
Bruce Cran wrote: > > On Sat, 10 Jul 2010 08:05:29 -0400 > Sergey Babkin wrote: > > > Basically, every time you use UDP, you've got to reinvent your > > own retransmission and reliability protocol. And these protocols > > are typically no good at all, as the story with NFS switching > > from UDP to TCP and improving the performance shows. At the same > > time TCP provides a very good transport control logic, so why not > > just reuse this logic in a library to solve the UDP issues once > > and for all? > > Have you looked at SCTP? It may provide the features you've looking > for: > http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol#Motivations Thanks, it does look like it! -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"
Re: TCP over UDP
Pieter de Goeje wrote: > > On Saturday 10 July 2010 14:05:29 Sergey Babkin wrote: > > Hi guys, > > > > I've got this idea, and I wonder if anyone has done it already, > > and if not then why. The idea is to put the TCP logic over UDP. > > > > I've done some googling and all I've found is some academical > > user-space implementations of TCP that actually try to interoperate > > with "real" TCP. What I'm thinking about is different. It's > > to use the TCP-derived logic as a portable library that would > > do the good flow control, retransmitting, delivery confirmations > > etc over UDP. > > > TCP actually scales pretty well. All modern operating systems provide a way to > do efficient select() operations, for example with FreeBSD's kqueue. Using a > small bit of tuning one can effectively deal with 100k+ TCP connections on a Not in a single process though. > single system. This mainly has to do with increasing the maximum number of > filedescriptors and decreasing the maximum send/receive buffer sizes to > conserve memory. Only in theory. My practical experience goes like this: How many parallel clients can our multithreaded server handle? Why, it should be easy to scale to almost anywhere, just bump the limit on the file descriptors. Bumped, tried. It crashes soon after 1000 connections. Why? A week later, the investigation has shown that we use PAM, and a PAM library for network authentication opens its own socket, and calls select() on it. It uses the standard fd_set, so when the socket happens to be above 1024, it corrupts the stack. So the only way to get a large number of file descriptors is in a very controlled environment, making sure not to use any 3rd-party or system libraries that might ever want to call select(). > TCP provides very good throughput, and it achieves this using large send and > receive buffers. Your userspace implementation will need to implement > something similar. A few hundred bytes per connection is simply not enough. A hundred or less bytes just for the state, for a connection that doesn't transfer anything at the moment. HTTP 1.1 and SOAP services on top of it do this: open a connection, and then after the first request keep it open, in case if they would want to send more requests. The minimum state would be pretty much a pair of addresses and sequence numbers, plus whatever tree or hash table overhead used to organize them. > If you want to deal with millions of clients, your protocol shall better not > have any state at all. A good example of this is DNS. DNS is actually a very bad example IMO. A very fragile protocol that trips over itself all the time. On the contrary, it's another case that should be able to benefit a lot from TCP-over-UDP. -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"
Re: TCP over UDP
Dirk-Willem van Gulik wrote: > > On 10 Jul 2010, at 13:05, Sergey Babkin wrote: > > > I've got this idea, and I wonder if anyone has done it already, > > and if not then why. The idea is to put the TCP logic over UDP. > > Have you looked at T/TCP [1,2,3] ? > > Dw > > 1: http://www.manpages.info/freebsd/ttcp.4.html > 2: http://en.wikipedia.org/wiki/T/TCP > 3: > http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack%20-%20Presentation.pdf It's been a sort of a remote inspiration :-) A major problem with it (besides the security stuff listed on Wiki) is that it's implementation is in-kernel, and as such can be used directly only when the OS has the implementation. There is no way to write a portable application with it. Other than that, I'm proposing an opposite approach: why bother about reducing the cost of the initial connection, if we can instead just open the connection once and then keep it open for a very long time at a low cost? -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"
TCP over UDP
Hi guys, I've got this idea, and I wonder if anyone has done it already, and if not then why. The idea is to put the TCP logic over UDP. I've done some googling and all I've found is some academical user-space implementations of TCP that actually try to interoperate with "real" TCP. What I'm thinking about is different. It's to use the TCP-derived logic as a portable library that would do the good flow control, retransmitting, delivery confirmations etc over UDP. Basically, every time you use UDP, you've got to reinvent your own retransmission and reliability protocol. And these protocols are typically no good at all, as the story with NFS switching from UDP to TCP and improving the performance shows. At the same time TCP provides a very good transport control logic, so why not just reuse this logic in a library to solve the UDP issues once and for all? Then of course, why not just use TCP? The problem of TCP is that it's expensive. It uses the kernel memory for its contexts. It also requires a file descriptor per each connection. The file descriptors are an expensive resource, and besides, even if the limit is raised, there is the issue with historic select() fd_set allocating only 1024 bits and nobody checking for the overflow. Even if your own code is carefully designed to avoid using select() at all and/or create large enough bitmasks, it could always happen to use some stupid library that doesn't do that and causes the interesting one-bit memory corruptions. Moving the connection logic to the user space makes the connections cheap. A hundred bytes or so per connection state is no big deal, you can easily create a million of these connections to the same process. All the state stays in the user-space pageable memory. Well, all of them sending data at the same time might not work so well, but caching a large number of currently inactive connections becomes cheap. Think of XMLRPC or SOAP or anything else over HTTP reusing the same TCP connection for multiple sequential requests. Now there is a painful balance of inactivity timeouts: make them too long and you overload the server, make them too short and the connections get dropped all the time. The cheap connections would allow to keep the much longer timeouts. Then there are other interesting possibilities arising from the easy access to the protocol state. The underlying datagramness can be exposed to the top level, and this immediately gives the transactional TCP. Or we could look at the state and find out if the data has been actually delivered to and confirmed by the other side. Or we can even drop the inactive connections at the server without notifying the client. Then if the client sends more requests on this connection, the server could semi-transparently re-establish it (OK, this would require an extension from TCP). Or we can do the better keep-alives, not the TCP's hour-long ones, but something within a few seconds (would not work too well with millions of connections, but it's a different use case where we want to detect the lost peer fast). Or having "sub-channels", each with its own sequence number. If the data gets transferred over 100 parallel logical connections, few bytes at a time for each of them, combining the whole bunch into one datagram would be much more efficient tahn sending 100 datagrams. These are just the ideas off the bat, there's got to be more of these interesting usages. It all looks like such an obviously good idea, that I wonder, why didn't anyone else try it before? Or have they tried it and found that it's not such a good idea after all? -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"
Re: /etc in CVS
Doug Barton wrote: > > On 4/20/2010 11:30 AM, Bakul Shah wrote: > > > > My suggestion was in the context of upgrding a system to a > > new release. There are changes to /**/etc/**/*(.) files going > > from release R to R+1. I was pointing out that what > > mergemaster does (merging in these changes to your locally > > modified etc files) is almost exactly the same as merging in > > a vendor branch under CVS (vendor here would be freebsd.org). > > But merge conflicts have to be resolved carefully and before > > any reboots! > > That's not accurate. By default mergemaster does nothing, it will not > change your installed /etc at all. At this point the -U option will > handle major release upgrades quite painlessly, leaving only those files > that actually have local mods for the user to deal with manually. > > Of course, I have always said that if anyone feels compelled to create a > better solution for etc merging that they should feel free, and I still > mean that. :) I wonder if a version control system, like SVN, could be used to keep track of all the changes in /etc. (Or maybe it already is and I'm simply out of date). -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"
book on parallel programming
Hi all, For everyone who asked about my book "The Practice of Parallel Programming" being printed, I've got it self-published through CreateSpace: https://www.createspace.com/3438465 They say it should get to Amazon too, in 3 weeks or so. The discount code RYM7VM5Q gives $14 off the list price at the CreateSpace store. The online free version is still available at http://members.verizon.net/~babkin/tpopp/ Though the printed edition has quite a few improvements in it :-) -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"
Re: Sudden mbuf demand increase and shortage under the load
Maxim Sobolev wrote: > > Hi, > > Our company have a FreeBSD based product that consists of the numerous > interconnected processes and it does some high-PPS UDP processing > (30-50K PPS is not uncommon). We are seeing some strange periodic > failures under the load in several such systems, which usually evidences > itself in IPC (even through unix domain sockets) suddenly either > breaking down or pausing and restoring only some time later (like 5-10 > minutes). The only sign of failure I managed to find was the increase of > the "requests for mbufs denied" in the netstat -m and number of total > mbuf clusters (nmbclusters) raising up to the limit. As a simple idea: UDP is not flow-controlled. So potentially nothing stops an application from sending the packets as fast as it can. If it's faster than the network card can process, they would start collecting. So this might be worth a try as a way to reproduce the problem and see if the system has a safeguard against it or not. Another possibility: what happens if a process is bound to an UDP socket but doesn't actually read the data from it? FreeBSD used to be pretty good at it, just throwing away the data beyond a certain limit, SVR4 was running out of network memory. But it might have changed, so might be worth a look too. -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"
book on parallel programming
Hi guys, I wrote a book, "The Practice of Parallel Programming". However the publishing part didn't work out, so I've put it on the web: SourceForge page: https://sourceforge.net/projects/tpopp/ read online: http://members.verizon.net/~babkin/tpopp/ BTW, looks like DamonNews is dead? All there is left is the emblem and some strange blog. All the rest is gone, including the archives of old issues. -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"
Re: is RTL8139 THAT bad?
Wojciech Puchar wrote: > > > Wojciech Puchar writes: > >> Why it's THAT bad? > > > > http://svn.freebsd.org/base/head/sys/pci/if_rl.c > > > > Scroll down past the copyright, license and attribution. Read the > > 38-line comment that explains just how crappy this chip really is. > > Well - really "low end". > > But - this computer can do memcpy at 80MB/s, so at 3.5MB/s it should be 5% > CPU for memcpy, and one interrupt per one packet (2500 packets/s). > > Is something more that make it consume >50% CPU? Accessing the on-card memory through PCI is guaranteed to be slower than the main memory, and depending on the particular card it may be much slower. -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"
Re: Patch for MS Hyper V (virtualization)
John Baldwin wrote: > > On Tuesday 07 April 2009 9:14:26 pm Sergey Babkin wrote: > > 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. > > Ok. > > > 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. > > Your printf() probably isn't in the right place. pci_add_map() uses > PCIB_READ_CONFIG() directly and doesn't use pci_read_config(), so if your > printf is in pci_read_config_method() in pci.c it won't see them. Try > hooking the cfg operations in sys/amd64/pci/pci_cfgreg.c instead. The printf was in pci_write_config(). -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"
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"
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 original > > > premise 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. 3D"mailto:j...@freebsd.org"; 2. 3D"mailto: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: Patch for MS Hyper V (virtualization)
John Baldwin wrote:
>
> On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote:
> > 2009/4/6 John Baldwin :
> > > 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.
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.
-SB
--- dev/pci/pci.c.0 2009-04-06 21:35:26.0 +
+++ dev/pci/pci.c 2009-04-06 22:43:08.0 +
@@ -3590,6 +3590,18 @@
struct pci_devinfo *dinfo = device_get_ivars(child);
pcicfgregs *cfg = &dinfo->cfg;
+ /* A workaround for Hyper-V that hangs on VM stop
+* if the base address register of the 21140 simulator is written;
+* since on Hyper-V the value written is the same as the one
+* already in the register, it can be simply skipped.
+* 0x1011: DEC, 0x0009: 21140 */
+ if (dinfo->cfg.vendor == 0x1011 && dinfo->cfg.device == 0x0009) {
+ if (reg == PCIR_BARS
+ && (val & ~3) == (PCIB_READ_CONFIG(device_get_parent(dev),
+ cfg->bus, cfg->slot, cfg->func, reg, width) & ~3) )
+return;
+ }
+
PCIB_WRITE_CONFIG(device_get_parent(dev),
cfg->bus, cfg->slot, cfg->func, reg, val, width);
}
___
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: Improving the kernel/i386 timecounter performance (GSoC proposal)
Apr 4, 2009 02:02:07 PM, jul...@elischer.org wrote: >Hey Sergey, whatever you are using for a mail client SUCKS >real bad at the moment.. > > it's really messing up your outgoing mails.. > >note the mail below Looks like using the text mode didn't help :-( Oh, well, I guess I should not write replies from the web interface. -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"
Re: Patch for MS Hyper V (virtualization)
Apr 4, 2009 02:10:23 PM, ivo...@freebsd.org wrote: >Can someo= ne please review and commit (if appropriate) the tweak for >Hyper-V shu= tdown issue at http://shell.peach.ne.jp/aoyama/archives/40 >? > = >>The problem is: the VM appears to hang on shutdown without it (hanging >the Hyper-V VM with it so the host also can't shutdown or reboot >re= liably - someone at MS skipped the part where an error in the VM >isn't= supposed to bring the host down with it) I don't have the commit = permission any more but I can review :-) Yes, Hyper-V does not like th= e writes into the PCI config space. Very specifically, writing the base= register window address of the simulated 21140 screws up something tha= t prevents the VM from shutting down. Interestingly, even reading and writi= ng back the same value has this effect. So the patch is valid. = >I don't particularly like the hackish checking for the 21140 chip, and I'= m not sure if if would break some real 21140 chip out there. If the dri= ver does the same as another one I've seen, the driver tries to align t= he register window to 0x80, and in the simulated 21140 it's already ali= gned. I've had a quick look but couldn't say it for sure. I'd do it dif= ferently: check if the value being written is the same that was read, = and skip the write in this case. Let me see, maybe I'll make a dif= ferent patch. -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"
Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
Apr 2, 2009 01:03:48 AM, [1]peterjer...@optushome.com.au wrot= e: >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobo...@freebsd.org> wrote: >>You don't really need to = do it on every execve() unconditionally. It >>could be done on de= mand in libc, so that only when thread pass certain >>threshold, = the "common page optimization code" kicks in and does its >>open/= mmap/etc magic. Otherwise, "normal" syscall is performed. > >Th= is "optimisation" is premature. First step is to implement an >appro= ach that always maps (or whatever) the data and then gather some >inf= ormation about its overheads in the real world. If they are deemed >= excessive, only then do we start looking at how to improve things. >A= nd IMO, the first step would be to lazily map the page - so it's not >= ;mapped by default but mapped the first time any of the information in &= gt;it is used. Does it make sense to even bother with lazy mapping? = After all, this is a very minor activity compared to mapping and linking= the dynamic libc. I think the overhead won't be even noticeable. If you= already map 200 pages, adding one more should not make much difference. -SB References 1. 3D"mailto:peterjer...@optushome.com.au"; 2. file://localhost/tmp/3D"m___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
Would not a normal mmap be duplicated on fork? I'd do it as a small
pseudo-= driver
that allows to mmap this page. Then libc would open this pseudo-d evice
and mmap it,
either in the on-load handler or on the first call of gettimeofday(). I
think, that should
be it, no special magic nece= ssary.
The per-process is more difficult and would require the magic= :-) Or
maybe
no magic a s such: just mmap the file from the /proc files= ystem.
Then on fork
in the child unmap this page, open the new file, and= map it. vfork
will still be tricky :-)
It also means wasting an extra p= age per process.
-SB
Mar 27, 2009 12:51:56 PM, [1]sco...@samsc= o.org wrote:
I've been talking about this for years. All I need is help with the VM
magic to create the page on fork. I also want two pages, one gl obal
for gettimeofday (and any other global data we can think of) and
on= e
per-process for static data like getpid/getgid.
Scott
Sergey Babkin wrote:
> (Sorry for the top quoting). Probably the= best implementation of
> gettimeofd=y() is to have
> a= page in the kernel mapped read-only to all the user
pr=cesses. Put
&g= t; the kernel's idea of time
> into this page. Then getting the= =ime becomes a simple read
(OK, two
> reads, to make sure that<= br>> no update =as happened in
between).
References
1. file://localhost/tmp/3D"mai___
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: Improving the kernel/i386 timecounter performance (GSoC proposal)
(Sorry for the top quoting). Probably the best implementation of
gettimeofd= ay() is to have
a page in the kernel mapped read-only to all the user pr= ocesses. Put
the kernel's idea of time
into this page. Then getting the = time becomes a simple read (OK, two
reads, to make sure that
no update = has happened in between).
The TSC can then be used to add the precis= ion between the ticks of
the kernel timer:
i.e. remember the value of TS= C when the last tick happen, and the
highest rate at which
TSC may be ti= cking at this CPU, and export in the same page. This
would guarantee thatthe time is not moving back.
However there are more issues with TS= C. TSC is guaranteed to have
the same value
on all the processors that s= hare the same system bus. But if the
machine is built of multiple
buses = with bridges between them, all bets are off. Each bus may be
stopped, resta= rted
and clocked separately. There is no way to tell, on which CPU is th= e
process currently
runnning, and it may be rescheduled do a different C= PU right before
or after the RDTSC
instruction.
-SB
Ma= r 26, 2009 06:55:04 PM, [1]...@phk.freebsd.dk wrote:
In message <[2]17560ccf0903260551v1f5cba9eu8
7727c0bae7b...@mail.gmail.com>, Prasha
nt Vaibhav writes:
= >The gettimeofday() function's implementation will then be
>change= d to read the timestamp counter (TSC) from the processor,
and use the
&g= t;reading in conjunction with the timing info exported by the
kernel to
= >calculate and return the time info in proper format.
I take it a= s read, that you know that there are other relvant
functions than gettim= eofday() and that these must provide a
monotonic timescale when queried = interleaved ?
Be aware that the TSC may not be, and may not stay syn= chronized
across multiple cores.
Further more, the TSC is not con= stant frequency and in particular
not "known frequency" at all times.
There are a lot of nasty cases to check, and a nasty interpolation
= required, which, in my tests some years back, totally negated any
speedu= p from using the TSC in the first place.
At the very minimum, you wi= ll have to add a quirk table where
known good {CPU+MOBO+BIOS} combinatio= ns can be entered, as we
find them.
>This will also pave way f= or optionally making the
>FreeBSD kernel tickless,
Rubbish. T= imecounters are not even closely associated with the
tick or ticklessnes= s of the kernel. [1]
> - The TSC frequency might change on cert= ain processors with
non-constant
> TSC rate (because of SpeedStep, = dynamic freq scaling etc.). The
only way to
> combat this is that t= he kernel be notified every time the
processor
> frequency changes.= Every cpu frequency driver will need to be
updated to
> notify the= kernel before and after a cpu freq change.
That is not good enough= , the bios may autonomously change the cpu
speed
and the skew from not k= nowing exactly _when_ and _how_ the cpu
clock
changed, is a significant = number of microseconds, plenty of time
to make strange things happen.
You will want to study carefully Dave Mills work to tame the alpha
= chips wandering SAW clocks.
Poul-Henning
[1] In my mind, rewo= rking the callout system in the kernel would
be a much better more neded= and much more worthwhile project.
--
Poul-Henning Kamp | = UNIX since Zilog Zeus 3.20
[3]...@freebsd.org | TCP= /IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
N= ever attribute to malice what can adequately be explained by
incompetence.<= br>___
[4]freebsd-hack...@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to "[6]fre
ebsd-hackers-unsubscr...@freebsd.org"
References
1. 3D"mailto:p...@phk.freebsd.dk";
2. file://localhost/tmp/3D 3. 3D"mailto:p...@freebsd.org";
4. 3D"mailto:fre 5. 3D"http://lists.=/
6.
3D"mailto:freebsd-hackers-unsub___
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
Sorry if this sounds like s tupid suggestion, but have you thought abou= t doing an user-space prototype first? It's usually much easier to deve= lop and modify. Then after the features get worked out, move it into the= kernel. -SB Mar 21, 2009 07:51:18 AM, [1]gabriele.mod= e...@gmail.com wrote: Hello, I am an AI master student at the university of = Amsterdam. On of my current research interests lays in the area of i nformation retrieval and I would like to do a project within my Unive= rsity research group starting next june. I am actually studying back= ground literature about semantic filesystem and information retrieval ov= er local files. Being also quite interested in kernel development, I= would like to propose a proof of concept that implements such technique= s. My goal, though, would not be just a reimplementation of existing = code, but possibly some more extensive work that combines techniques alr= eady used in other domains of II. Could this be an interesting Summe= r of Code proposal for the FreeBSD Foundation? I plan to write down = some notes/ideas (and details) I have on a wiki starting from next week. Regards. ___ = [2]freebsd-hack...@freebsd.org mailing list [3]http://lists.freebsd.org/mailman/listinfo/fr= eebsd-hackers To unsubscribe, send any mail to "[4]freebsd-hackers-unsubscr...@freebsd.org" References 1. 3D"mailto:gabr 2. 3D"mailto:freebsd-hackers@freebsd.org"; 3. 3D"http://lists.freebsd.org/mailman/listinfo/freebsd-hackers"; 4. 3D"mailto:fr___ 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: bus_dma (9). What exactly means "Loading of memory allocation" ?
If I remember correctly, loading means that the pages become mapped and= visible to the devices. Some buses can access only a limited address space= , like ISA has only a 24-bit address. When a map gets loaded, for any pages= outside of this range the temporary in-ramge pages are allocated and the d= ata gets moved through them. On some machines, like I think DEC Alpha, the = physicall addresses seen by the devices are not the same as seen by the CPU= , these need to be translated. And so on. I think my real old articl= e had some of these explanations but now the Daemonnews site seems to be re= al slow: http://ezine.daemonnews.org/28/isa.html -SB (sorry a= bout top quoting, it's the only kind the web interface of my provider suppo= rts) Feb 1, 2009 03:38:27 PM, [1]bsd.qu...@googlemail.com = wrote: = Hi, at first the cut of text from man (9) bus_dma: bus_dmamap_t = A machine-dependent opaque type describing an individual mapp= ing. One map is used for each memory allocation that will b= e loaded. Maps can be reused once they have been unloaded..= . Question: What exactly means "Loading of memory allocation" in thi s context ? Could anyone explain it or give me some little example wi= th DMA functions for understanding it. References 1. 3D"mailto:bsd.qu...@googlemail___ 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: TCSBRK not implemented in linux compat
>While trying to get = a linux binary running on FreeBSD I encountered
>the following prob= lem during serial port I/O.
>
>Dec 1 22:22:34 soekris kernel: = linux: pid 7239 (linuxbinary): ioctl
>fd=0, cmd=0x5409 ('T',9) = is not implemented
>
>0x5409 turns out to be TCSBRK, which is = not implemented (yet?). Can
>anyone give me some clues where / how = to start implementing this?
It
>seems like the linux way of handlin= g it is to call tcdrain(), but
I'm
>not sure as to how this transla= tes to the FreeBSD compat layer.
It should probably be translated to= the same BSD call. What it does
is
drain the buffer then send the seria= l BREAK signal: a low-voltage
signal lasting
longer than the length of o= ne normal character. The other side can
detect this and generate
an inte= rrupt, which then may get translated to a signal (see the
stty parameters&n= bsp;
ignbrk, brkint).
-SB
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
Jeremy Chadwick wrote: > > What really needs to happen here should be obvious: we need some form of > inexpensive keyboard-only USB support in boot2/loader. > > I would *love* to know how Linux and Windows solve this problem. If I remember right, UnixWare used(s) the BIOS calls in the loader. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.4 - filesystem full
Varshavchick Alexander wrote: > > I have an old enough server with FreeBSD 5.4 which from time to time > complains about filesystem full. But the problem is that the partition > in question has about 15G free space and more than 1000 free inodes. > Then all by itself the error dissapears, only to be repeated several hours > later. What can it be and where to look? The server runs mainly apache and > sendmail, nothing special. I vaguely remember that there was an issue with softupdates that didn't report blocks as free until the filesystem was synced, and with intense disk activity the filesystem was not syncing by itself often enough. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: massive interrupt storm
Murray Taylor wrote: > > Hi all, > > We have just purchased some servers with a view to > using them as firewalls within our WAN, and have discovered that > they are suject to a massive interrupt storm on IRQ17. > > systat -v is showing 59000 -> 63000 interrupts continuously > on this IRQ, and 90%->98% Interrupt CPU usage One typical reason for "interrupt storms" is this: Some device has been initialized by BIOS and has indicated an interrupt but there is no driver in the OS to handle this interrupt. PCI allows sharing of the interrupts, i.e. multiple devices show their interrupts on the same IRQ line. The interrupt is signalled by level, i.e. if any device on this IRQ has an interrupt pending, it would pull the line low. OS has no way to tell which one, other than by trying all the drivers for the devices sitting on this line. Once the driver has found that its device is the one signalling interrupt, it services it, cleans the device state, and the device lets go of the IRQ line. The trouble starts when there is some device for which there is no driver. OS runs its interrupt handler, polls each driver, each of them says "nope, not mine", teh interrupt handler exits and gets called again right away. The fix is to disable the unsupported devices in BIOS or at least collect them on some IRQ line that is not used by any supported devices. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: time used by a thread
>I want to use getrusage to see how much time a program is using. But >this is a multithreaded program, and I just want the time taken by that >particular thread! > >I know this info must be available somewhere, because top -H seems to >provide it. But getrusage seems to give the total rusage for the whole >program, not just the thread. > >Any ideas? I would especially appreciate a portable solution that works >for OS other than FreeBSD (e.g. linux, etc as well). On Linux and Solaris it can be done by reading the /proc filesystem. Probably on FreeBSD too, haven't tried. But it's different on each OS. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: C++ exceptions are broken in FreeBSD with gcc-compiled code?
Oh, this reminded me of something I've seen before. In some version of GCC
(3.96? 4.something?) if you declare a function with an explicit throw()
declaration and then throw from it an exception that is not in the declaration,
the exception never gets caught. It just goes all the way out.
Any chance that this is one of these cases?
I don't remember the exact details but it looked
somewhat like this:
void f() throw exception;
voif f()
{
throw(string("zzz"));
}
main()
{
try {
f();
} catch(exception e) {
...
} catch (string s) {
...
}
}
-SB
>
>> > It works fine for me too, using FreeBSD 6-stable and the built-in gcc
>> > 3.4.6
>> > as well as with gcc 4.2.4 20080305 installed from ports.
>> > No need to use -pthreads in either case
>>
>> This means that this issue is STABLE-7.0 specific.
>
>I am not able to reproduce the problem here; I will compile the
>updated sources tonight to check if that changes anything:
>
># uname -sr
>FreeBSD 7.0-STABLE
>
># g++ --version
>g++ (GCC) 4.2.1 20070719 [FreeBSD]
>Copyright (C) 2007 Free Software Foundation, Inc.
>This is free software; see the source for copying conditions. There is NO
>warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
># cat exc.C
>
>#include
>#include
>using namespace std;
>
>int main() {
> try {
>throw string("String");
> } catch (string s) {
>cout << "Caught an exception \"" << s << "\"\n";
> }
>}
>
># g++ -o exc exc.C
># ./exc
>Caught an exception "String"
>___
>freebsd-hackers@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: vkernel & GSoC, some questions
>From: Matthew Dillon >To: John Baldwin <[EMAIL PROTECTED]> >:Except that you still need "real" hardware concurrency to see some races and >:that is important for testing. I'd worry about the overhead of any > >Hardware and vkernel/qemu environments exercise different code paths >and different timing mechanics. Certain bugs show up on vkernel's >more readily then on real hardware, while other bugs show up more >readily on real hardware then on vkernel's. I don't think one is When testing multi-threaded code I sometimes insert artificial delays at different strategic locations. This widens any present race windows and makes the related bugs show up every time instead of once in a while. Of course, the resulting code works slower during the tests too :-) -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Stale mount on disconnected device: how to delete it?
> >On Mon, Dec 17, 2007 at 03:07:02AM -0800, Yuri wrote : >> I had USB camera connected and recognized as umass0 and mounted as >> /mnt/camera >> on /dev/da0s1. >> >> Camera was disconnected while it was still mounted. > >Personal recipe when this kind of things happens (generally caused by a >camera switching to power-save mode or that runs out of battery): Would not umount -f do the trick? -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: msleep() on recursivly locked mutexes
>From: Julian Elischer <[EMAIL PROTECTED]> >Basically you shouldn't have a recursed mutex FULL STOP. We have a couple >of instances in the kernel where we allow a mutex to recurse, but they had to >be >hard fought, and the general rule is "Don't". If you are recursing on >a mutex you need to switch to some other method of doing things. >e.g. reference counts, turnstiles, whatever.. use the mutex to create these One typical problem is when someone holds a mutex and needs to call a function that also tried to get the mutex. The typical solution for it is to provide two versions of this function, one expecting the mutex being already held by the caller, the other being a wrapper that grabs the mutex and then calls the actual worker function. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: serial help ?
>
>I'm working on some custom hardware and I'm getting garbled console
>output.
>
>I noticed that siocntxwait looks like this:
>
>static void
>siocntxwait(iobase)
> Port_t iobase;
>{
> int timo;
>
> /*
>* Wait for any pending transmission to finish. Required to avoid
>* the UART lockup bug when the speed is changed, and for normal
>* transmits.
>*/
> timo = 10;
> while ((inb(iobase + com_lsr) & (LSR_TSRE | LSR_TXRDY))
> != (LSR_TSRE | LSR_TXRDY) && --timo != 0)
> ;
>}
>
>Shouldn't there be some sort of DELAY in there?
>
>My platform has an emulated serial device in hardware, so it
>may be that the loop could run a LOT faster than transmit can
>happen...
>
>any ideas of what the DELAY should be?
I would do something like delay(1) in the loop after
this one. The idea being that if the output buffer
is empty os nearly empty, the first loop will exit
quickly and skip the second one. Otherwise it would
go into the slow loop with delay().
Then for the 2nd loop count limit I guess take the size of the
hardware buffer, multiply by 10 (8 data bits + 2
start/stop), add a little for safety and divide the bit rate
by that, and then divide the length of delay(1) by that. Or however
long it takes for your device to transmit. If the
actual transmission happens faster, it will set the
TXRDY bit and the loop will complete faster.
-SB
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /etc/group limits (REAL limits)
>From: Eric Anderson <[EMAIL PROTECTED]> >On one of my boxes where I have a decent amount of (less than 50) users >in a few groups, I finally hit the limit. Not 1024 bytes though (that I >know of). When that happens though, it is sooner than expected, and >tools (like 'id') seg fault (and core dump). > >I have a sample group, and it appears to be hitting the byte limit. If >I add a single additional character to the group, it will break things. > It appears to be a combination of multiple groups. > >Can someone with some experience in this area comment? I can send the >group file itself if needed. The traditional workaround for the 1024 bytes limit is to have multiple lines for the same group, for example: group1:x:100:user1,user2,user3 group1:x:100:user4,user5,user6 Note that everything except the list of the users is the same on all the lines. It might work for you too. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: "tar -c|gzip" faster than "tar -cz"?!?
>From: Oliver Fromme <[EMAIL PROTECTED]> > > > The tar|gzip command uses 18% less CPU and is 10% faster. It > > > is clear the HDD is the bottleneck. > > > > Now it's clear to me :) > > > > This makes sense if tar is single-threaded: there's only one thread of > > execution, and it can either be waiting on the disk, or compressing > > data. With two processes, gzip can compress while tar blocks on disk > > IO. > >No. During my tests there was no physical disk I/O (the >disk LED was *OFF* all the time). So tar certainly wasn't >blocking on disk I/O. > >The difference in CPU time (and wall clock time) seems >simply to be caused by different compression code. gzip >is noticeably more efficient than libz, at least on the >OS/processor combination where I tested it (Athlon64 with >FreeBSD/i386 6.2-PRERELEASE). Any chance that gzip uses a different version of libz? Or maybe the buffer size is different? Yet another possibility could be if tar calls zlib with the SYNC (or is that FLUSH? something like that) flag on each chunk, this would kill both the performance and the compression rate. Then again, the default compression level may be different (but it should be making the speed higher if the ratio falls lower). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: SOCK_DGRAM optimization needed...
>From: Gleb Smirnoff <[EMAIL PROTECTED]> >On Fri, Aug 18, 2006 at 10:41:36AM +0300, Martin Eugen wrote: >M> I have a simple application, that deals with lots of dgram sockets (UDP). >M> Thousands of them. Basically, its purpose is to >M> maintain pairs of sockets and when data is received on one of the sockets it >M> peeks through it (doing some simple >M> statistic calculations) and then forwards it to the other socket. >M> Because of the hudge number of reads and writes (probably about a 10 packets >M> per second per socket pair) it generates a significant load >M> on the system, that I would like to minimize. I'm currently evaluating if it >M> would be possible to add simple 'routing' functionality in the socket layer >M> in the kernel, because frankly I'm not able to think of anything else. > >As Robert said you can try to put this into kernel. That is, you can >write down a netgraph node, that does the routing. Then connect thousands >of ng_ksocket(4) to it. > >If netgraph(4) survives such a big graph (I hope so), you will get quite >fast forwarding. You should also implement a fast ng_findhook method I think it doesn't have to be a big graph. Just make your module sit under IP and look inside all the packets coming up. If the packet matches one it's looking for, update the stats, change the port number and send it up to the IP node. Otherwise just send it to the IP node. With this approach you won't even really need the changing of port numbers if all you do is the stats, just make the "real" app listen on the same ports as where the packets are sent to. BTW, some many years ago I wrote a STREAMS generic IP traffic accounting module that worked like this. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Aqcuiring full path to running process from outside the kernel
>From: Lutz Boehne <[EMAIL PROTECTED]> > >> but argv[0] is either an absolute path or a path relative to pwd, >> unless your shell is broken. > >One should also consider users breaking argv[0] intentionally, e.g. >pointing it to other files which could lead to undesired/unpredictable >behaviour. Even as a fallback it's probably not wise to trust it. If we get back to the question of why we need the file, we might not need it at all. As far as I understand, the problem is that the Watcom compiler works by sticking a set of messages into the executable files and then later reading them out of the file, and the point is to adapt the compiler to work on FreeBSD. So why not just change the compiler to put the contents of this file into a DATA section, at some special symbol. (I presume that now it puts the messages into some kind of a COMMENT section). Then instead of reading the file manually you would have the contents of the file already pre-mapped into the memory for you when the program starts. Saves you lots of trouble. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: disklabel differences FreeBSD, DragonFly
>to followup myself ... I just see, we also have pack identifier, >its the additional struct behind it that differs. >"Bootstrap name" etc... Those are parts of an union, so the total size still shouldn't change. I'd guess that the char[] format is used on-disk and the pointers are used in-memory. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Re: Programs not accepting input?
>From: Peter Jeremy <[EMAIL PROTECTED]> >>BTW, I've promised Greg a script to dump the X protocol >>from binary log, then I was busy and and forgot about it. >>Is there still any interest in this tool? > >What does your script do? I've used xmon in the (distant) past but >it is designed to sit in the middle of an X connection. I think >Wireshark can decode X11. It takes a hex dump produced in whatever way (kdump, strace or maybe tcpdump) and tries to decode the X protocol fields in it. The dump can be made at either client or server side and can include both sides of transmissions (with separators between the portions of the file). Converting the output of a tracing tool into a proper raw hex dump is a separate task. I have a script that does that with output of SVR4 truss. The information about the X protocol fields gets taken from a simplistic parsing of the slightly massaged X header files. At some point I neede to trace the X protocol and I didn't know about the other tools (your e-mail is the first time I hear about them), so I've made this script. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Programs not accepting input?
>From: Peter Jeremy <[EMAIL PROTECTED]> >To resurrect a fairly old thread... > >On Mon, 2006-Mar-27 11:23:42 +1030, Greg 'groggy' Lehey wrote: >>On Sunday, 26 March 2006 at 19:17:19 +1100, Peter Jeremy wrote: >>> My work system runs separate X servers on two heads (rather than >>> ximerama) and I have problems with windows occasionally refusing to >>> accept focus after I move the pointer from screen to screen (though >>> I can get an alternative window to accept focus and then switch back >>> to the window I originally wanted). This started after an X.org >>> upgrade but I'm not sure which one. >> >>Interesting. I've seen this one too: my mail window is at the left of >>the right-hand monitor on wantadilla (:0.1). Frequently when I move >>from :0.0 to 0:1, the window manager will highlight the window on >>:0.1, but focus remains with some window on :0.0. If I move further >>right and then back again, focus catches up with the correct window. > >I've been keeping a closer eye on my problem. I'm using fvwm1 with >click-to-focus and lose-focus-on-screen-switch. If I move from one >screen to another and quickly click on a window, the border changes >colour to indicate that it has focus but keyboard input is ignored. This is likely an fvwm1 problem. I use it too (without 2 monitors) and after some time something gets broken in its focus handling, and the windows stop getting focus. Restarting fvwm clears up the problem. >>That's mainly irritating; the problem I describe above is annoying. > >Did you get anywhere in debugging it? BTW, I've promised Greg a script to dump the X protocol from binary log, then I was busy and and forgot about it. Is there still any interest in this tool? -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: kern/99979: Get Ready for Kernel Module in C++
>From: "Kamal R. Prasad" <[EMAIL PROTECTED]>
>Im sorry I didn't understand you. setjmp() stores a few register contents
>[notably ip] in a jmpbuf -which are restored after a longjmp(). How is the
>try/catch mechanism more efficient than a setjmp()/longjmp() in terms of
>space/time complexity?
try/catch stores less. Besides, longjmp() is nothing like
try/catch. The whole point of try/catch is that as the
stack gets unwound, all the auto-class objects get
properly destroyed. When you do longjmp, you just move
the instruction pointer and stack pointer, and if
any of the objects on the stack contained pointers
to any dynamically allocated memory, it gets lost.
If there were any file descriptors opened along the way,
they are left open too. If there were any locks held,
they stay locked. To prevent this loss with longjmp, you
have to track all these objects manually.
Note that even with try/catch it's a Real Bad Idea to throw
exceptions from constructors and destructors, as this
causes complications.
-SB
>On 7/12/06, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote:
>> > On 7/12/06, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
>> >
>> > >On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote:
>> > >> Even if I have no proof-of-concepts (so maybe somebody can show that
>> > >> this is not fair), if we have setjmp/longjmp in the kernel we can
>> have
>> > >> a correct exception handling mechanism without not great problems.
>> > >
>> > >ROFL. Sorry, but using setjmp/longjmp is one of the worst possible
>> > >implementation of exceptions since it is very expensive for the hot
>> > >path, where you don't expect exceptions. They are called "exception"
>> for
>> > >a reason.
>> >
>> >
>> > so how is exception handling in C++ more efficient than
>> setjmp()/longjmp()
>> > -in either paths?
>>
>> The common implementations are based on two assumptions:
>> - try {} is used often through out the tree and nested
>> - exceptions are raised seldomly.
>> This means that the desire to catch an exception should be cheap and the
>> implementation optimised for that.
>>
>> What happens is that the compiler creates a table which allows automatic
>> stack unwinding and matching of the instruction pointers. The former is
>> necessary to handle frame pointer vs. frame pointer-less stack frames,
>> the latter is used to determine where an exception should be cought.
>>
>> Consider:
>> void bar()
>> {
>>throw "foo";
>> }
>>
>> void foo()
>> {
>>try {
>>bar();
>>} catch(...) {
>>cerr << "error";
>>}
>> }
>>
>> (don't try that, I haven't written C++ for ages)
>>
>> The compiler creates:
>> - an entry for the range of bar to annotate that it doesn't have use a
>> frame pointer
>> - an entry for foo, with the same annotation
>> - the address when bar is called in foo (or the address directly
>> following) to annotate that it should jump to catch, when an exception
>> is raised.
>>
>> When an exception is raised, it looks at the current instruction pointer
>> and begins unwinding the stack until a catch is found. This can be
>> relatively cheap compared to longjmp, since the register content does
>> not have to be restored. It does not add any slowdown, as long as
>> exceptions are not raised.
>>
>> Joerg
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>>
>___
>freebsd-hackers@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: kern/99979: Get Ready for Kernel Module in C++
>From: [EMAIL PROTECTED] >Jason Slagle wrote: > >> On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote: >> >>> I would repeat several sentences in my last reply. >>> Why would people write Windows application with rather MFC/ATL/.NET >>> Framework than direct Windows API? Why is gtkmm framework created for >>> GTK+? Would you write a X11 application with original X11 API, without QT >>> or other X11 toolkit? I believe the answer is that all programmers are >>> human begins, not >>> machines. Human programmer would reduce brainwork, even if an API >>> package/wrapper slightly reduces running efficiency. >> >> And this is why office 2003 takes longer to load on a 2.4ghz machine then >> office 97 did on a 233. >> >Why don't you say that Office 2003 is more powerful than Office 97? Hm, is it? I've never noticed, I guess I just don't have the need for the more powerful parts of it. >You even haven't known what we are discussing and what I would commit. >Actually my patches has little relationship to C++. What many C++ programmers don't realize is that lots of the C++ functionality (inheritance etc.) can be done in C almost as good and easy (and sometimes just as good and easy). And it's done, and people have pointed it out. There are some things in C++ that really are a great advantage over C (STL, for an easy example) but these tend to be pretty heavyweight to put them into the kernel. Then again, there are things in C++ that are very convenient and lightweight. One of them would be the automatic calling of destructors when exiting a block. Makes the tracking of the locks much easier. I'm not so sure that the exceptions get into this category. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: NFS server not responding prevents boot
>From: Steven Hartland <[EMAIL PROTECTED]> >> Anyway the big question is how can I change all our NFS >> mounts so that failed mounts dont prevent the machines >> booting to the point where they can be fixed remotely >> i.e. have started sshd. > >Doh!! spent ages googling for the answer then found it >in 2mins of looking through the man pages. > >The option for anyone interested is "bg" for -b from >the command line to mount: >[quote="man mount_nfs"] >-b >If an initial attempt to contact the server fails, fork off a I usually use "soft,bg". The "soft" option makes the operations on this filesystem fail if the server is not available instead of hanging (unkillable!) forever and waiting for the server to come up. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: [PATCH] Fancy rc startup style RFC
>From: Bill Vermillion <[EMAIL PROTECTED]> has some >color vision problem. Mine is a bit more than others. Everytime >I get called to work on a Linux system, I have to go in and disable >the colors as the reds and other colors become very hard to see >against a dark background. The problem is the luminance value of >colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. When I have time and patience to mess around, I set the LS_COLORS and such variables to the complementary bitmasks of what they've been, and that fixes the problem with contrast on the black background. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: What's in a (device) name?
>From: "M. Warner Losh" <[EMAIL PROTECTED]> >usb assigns addresses dynamically. Everyone else does it basically >statically. PCI slot/device numbers are static, but extreme >configurations can change the bus number. Some USB devices (though not all of them) provide a unique device ID. If this ID is available, binding to a particular device is straightforward. The problems start when the device get replaced. For example, an USB printer dies and you replace it with another one. Form a tech support standpoint it's convenient if the new printer gets silently recognized as a replacement of the old one. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Using any network interface whatsoever (solution?)
>From: Mike Meyer >In <[EMAIL PROTECTED]>, Darren Pilgrim <[EMAIL PROTECTED]> typed: >> >> That's far better than trying to remember what's on em0. >> > >> > That's certainly true. But is there an advantage to tieing the >> > PublicLAN name to a MAC address as opposed to em0? >> You could test two different drivers on the same hardware and you wouldn't >> have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: > >Yup, and this is an advantage. On the other hand, if you tie the >device name to the slot number (the real goal), you can swap different >hardware into that slot without having to modify any configuration >information at all. If you tie the name to the MAC address, you always Nope, there is more than one goal. Sometimes you want to tie the device name to the slot, so that you can change the cards seamlessly. Sometimes you want to tie the device name to the card, so that you can move the card around between the slots (this is especially true for USB where you can change the topology very easily). I think the better solution is to let the administrator decide which particular way of tying the names he wants to use for a particular card. (And maybe make some reasonable guess by default, maybe depending on the device type). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Using any network interface whatsoever
>From: Mike Meyer >In <[EMAIL PROTECTED]>, Scott Long <[EMAIL PROTECTED]> typed: >> Youre' saying that >> instead of /dev/da0, we should have >> /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0 > >That's a ridiculous extreme. All I advocated was that we be able to >easily identify the devices connected to the system, *not* that we be >able identify every device in the world. Sun solved disk device naming >back in the 80s. I think this is a problem consisting of multiple parts: 1. Identify physical devices and be able to access them. 2. Identify some stable "logical" names by device type, that stay fixed when the configuration changes. 3. Be able to find the mapping easily between these two. 4. Be able to change that mapping. USB is probably the subsystem that has a particular need in this kind of stuff. So, since we have devfs nowadays, why don't we just have multiple names (dev files) for the same device? For example, the same device can be named by driver aha0b0t0d0 and by logical type disk0. The 3rd part can be solved by using symlinks in devfs: i.e. disk0 would be a symlink to aha0b0t0d0, and you can do "ls" and find out what is linked to what. The 4th part can be solved by allowing the sysadmin to create symlinks in devfs. The network driver subsystem would obviously have to be changed to consult devfs for the device names. The next interesting question is how to keep these links persistent between boots. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: RFC: Adding a ``user'' mount option
>From: Stefan Sperling <[EMAIL PROTECTED]> >What are admins supposed to do on systems with more than, say, a hundred >users. Having to add a line to /etc/fstab for every user is of course >scriptable, but that does not make it less insane. Would it make sense to be able to specify a group in fstab? Then the users can be simply given membership of this group to mount the devices. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programs not accepting input?
Greg 'groggy' Lehey wrote: > > > The focus management and the highlighting of the window manager > > decoration are not physically connected in any way, so a bug in the > > window manager might cause it to do the highlighting but forget to > > give the focus to the application. > > But mouse focus and keyboard focus are the same, right? The windows > respond to the mouse, but not to the keyboard. There is no mouse focus. The mouse events are delivered to whatever window happens to be under the mouse pointer. Well, unless a pointer grab is in effect, but that's a separate story. > The remainder of your reply seems to build on the assumption that > there is no focus. I'll leave it there in case I misunderstood and > you want to refer to it. No, the remainder describes the case when the focus works correctly but the mapping from keycodes to keysyms gets somehow broken, so that the app gets the keyboard events but then it can't translate them into the text strings. Sorry, I couldn't look for the programs yet. -SB > > To debug that you can add debugging printout to the WM. Or I've had > > a script that sort of decoded the X protocol, so if you can get the > > dump of these (maybe with ktrace), you can decode the dump and see > > what happens with the focus. I'll look for it in my archives. > > > > If no, it might be something with the keyboard event translation to > > keysyms/text. You can debug this by writing a test program that > > would do it own dispatch loop - i.e. call XEvent() and then > > XtDispatchEvent() (or some close names - I might not remember them > > right), and print the debugging messages. So if you see that > > XEvent() is getting events but then nothing comes out of dispatching > > them, then the translation is broken somewhere. > > > > I might be able to find this kind of a program > > in my archives too, I'll look around. > > thanks. > > > BTW, one place where the keyboard events might disappear is the > > Input Method handling code. But I don't think that you run any Input > > Methods. > > Not explicitly. > > Greg > -- > See complete headers for address and phone numbers. > > > -- >Part 1.2Type: application/pgp-signature ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Programs not accepting input?
>Same here. As mentioned in the original message, I can use the mouse >to open a new window under firefox. The new window will accept >keyboard input, the old one won't. It's almost as if it's deadlocking >on input. > >Reminder: my final question was "how do I go about debugging this >problem?". Does it happen with any kind of programs? If yes, can you reproduce it with "xev"? If yes, it would probably be something focus-related (and you'd be able to see that the Focus event is not coming in). The focus management and the highlighting of the window manager decoration are not physically connected in any way, so a bug in the window manager might cause it to do the highlighting but forget to give the focus to the application. To debug that you can add debugging printout to the WM. Or I've had a script that sort of decoded the X protocol, so if you can get the dump of these (maybe with ktrace), you can decode the dump and see what happens with the focus. I'll look for it in my archives. If no, it might be something with the keyboard event translation to keysyms/text. You can debug this by writing a test program that would do it own dispatch loop - i.e. call XEvent() and then XtDispatchEvent() (or some close names - I might not remember them right), and print the debugging messages. So if you see that XEvent() is getting events but then nothing comes out of dispatching them, then the translation is broken somewhere. I might be able to find this kind of a program in my archives too, I'll look around. BTW, one place where the keyboard events might disappear is the Input Method handling code. But I don't think that you run any Input Methods. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: NetBSD disk backup over network
>From: Bernd Walter <[EMAIL PROTECTED]> >> >From: Ashley Moran <[EMAIL PROTECTED]> >> >> >I just saw this slashdotted article: >> >http://ezine.daemonnews.org/200603/dermouse.html >> >> Well, I've been running around with this kind of idea for >> around 10 years now. Never actually implemented it though. >> I can't quite believe that encryption at full disk speeds >> makes no noticeable CPU overhead. > >This sounds as nothing more than a mirror with one disk beeing a remote >file. >And this is not really a new idea - remote mirror has a long standing >tradition. >You can already configure these things with GEOM right now. >But this is in no way a backup, this just saves you from disk failures >which is the purpose of a mirror. >What is missing is history in the remote image so that one can access >older contents. You can easily save the stream of updates as a redo log (well, that's the idea I've been running around with). Then you can roll forward from the full backup points using this log, and also use it for online backups while the operations are still running. Of course, it would probably require an fsck to get things actually mounted. My impression from the article was that he had this thing as well. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NetBSD disk backup over network
>From: Ashley Moran <[EMAIL PROTECTED]> >I just saw this slashdotted article: >http://ezine.daemonnews.org/200603/dermouse.html > >Just to satisfy my curiosity, is it the sort of thing that can be implemented >as a GEOM layer? The idea is bloody clever but sounds like a bit of a hack >right now. Well, I've been running around with this kind of idea for around 10 years now. Never actually implemented it though. I can't quite believe that encryption at full disk speeds makes no noticeable CPU overhead. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Fastest timecounter ?
>From: David Malone <[EMAIL PROTECTED]> >The TSC is always fastest, but unfortunately under some circumstances >it can't be trusted (if your CPU has throttle modes to save power >or on some SMP systems where the two TSCs in each CPU give different >values). If I remember correctly, all the SMP CPUs on the same bus should give the same values (since they are synchronized and reset from the same signals). The discrepancy may appear on machines with multiple bridged front-side buses, essentially the NUMA machines (such as those with over 4 Intel CPUs). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Difference between signal related structures
>From: Pranav Sawargaonkar <[EMAIL PROTECTED]> >Hi >I am studying signaling related work in FreeBSD kernel just for learning. >Can anybody tell me that why there are two different structures named >1)struct sigcontext >2)struct osigcontext >are defined in /sys/i386/include/signal.h >I want to know what is basic difference between them? The one with "o" is "old". At some point the structure has been extended, and the old version got "o" added to its name. It's probably used for binary compatibility of the old programs, to convert the data between the old and new format. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: unversal watchdog
>From: Daniel O'Connor <[EMAIL PROTECTED]> >On Monday 27 February 2006 22:33, Tobias Roth wrote: >> > man rc.subr plus a look through /etc/rc.d should get you started :) >> >> Can you explain in more detail how one can handle the watchdog part of >> the equation? I can't find that information in the rc.subr manpage. > >Ahh sorry I think I misunderstood the question :( > >I was thinking a program to reset a hardware watchdog timer.. > >As to answer the question - I am not aware of any facility for automatically >restarting things (unless you can get init to do it via /etc/ttys somehow) Would a port of a Linux init do ? :-) You know, it's all separate packages on Linux and there is no reason why they can't be ported and used separately. Here is the package name from RedHat: $ rpm -qf /sbin/init SysVinit-2.85-4.2 I don't know if there is a ready port but it should be not THAT difficult to do. >I don't think it would be too hard to create a shell wrapper script though >(kind of annoying I admit) Well, it's been a long story now. Every time someone comes with the idea of adding init to BSD, other people feel very strongly that they hate init and that it must not be in BSD. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: volume serial number + volume label
>From: andrew clarke <[EMAIL PROTECTED]> > >How can I programmatically retrieve the "volume serial number" and >"volume label" of a removable disc in FreeBSD? This is the same >information that's presented by issuing a "dir" command in Windows: > > Volume in drive D is FooBar > Volume Serial Number is 58BB-96AA I've been reading on the Windows filesystems recently, so here is the quick answer: The serial number is contained in DOS/Windows partition's boot block, 8 bytes at offset 0x48. For the label you have to parse the DOS/Windows filseystem format. On FAT it's the name of the file in the root directory with the special attribute (VOL or LABEL - something like this, can't remember now). On NTFS it's stored I think as the attribute $VOLUME_NAME of the system file $Volume contained in the inode 3 of the Master File Table. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pre-loaded mfsroot size and FreeBSD 4.9 with 4G RAM
Jacques Fourie wrote: > > I have installed 6.0-RELEASE and the behaviour is still the same. If I try > to pre-load an md_image of 64M with 4G of RAM installed, the kernel panics > early in the boot cycle. Here is the panic on 6.0-RELEASE: > > 131072K of memory above 4GB ignored This is a kind of stupid question but is there any chance that the 64MB image overlaps with the PCI address hole? To elaborate: with 4GB memory installed there would be no address range to access the memory-mapped 32-bit PCI cards. So the motherboard circuitry relocates some amount of memory (the 128MB shown above) from some lower address to above 4GB and frees this address space below 4GB for mapping of the PCI cards. So the interesting question is: what is the address of this PCI hole and what is the loading address of the FreeBSD md_image? If they overlap then naturally a part of the image would go into nowhere and cause a panic. On my machine this PCI hole can be disabled in BIOS (I think so, there is also some kind of configuration in BIOS but I did not pay much attention to it as I don't have 4GB). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: speed up port compiling using RAM (tmpfs) ???
Kris Kennaway wrote: > > On Fri, Jan 20, 2006 at 04:54:33PM -0500, Sergey Babkin wrote: > > Kris Kennaway wrote: > > > > > > On Fri, Jan 20, 2006 at 11:25:33AM -0600, Sergey Babkin wrote: > > > > >From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]> > > > > > > > > >Gary Thorpe <[EMAIL PROTECTED]> writes: > > > > >> This effectively means that you cannot take advantage of SMP to > > > > >> compile FreeBSD's ports collection. That sounds like a big > > > > >> limitation...especially for people trying to speed up bulk builds. > > > > > > > > > >We cannot be held responsible for race conditions in the Makefiles of > > > > >third-party software. > > > > > > > > Well, maybe we can then build multiple ports in parallel. > > > > I guess the way to do it would be to run the top-level make with > > > > -j but then disable it when calling the makefiles of the > > > > individual ports. Not that I have any idea how to actually > > > > do that. > > > > > > It's harder than that, because you need to impose dependency > > > information and mutual exclusion between different makes. e.g. they > > > can't both be compiling the same port at the same time, which will > > > happen if you just do the naive thing. > > > > That's the part that "make -j" is supposed to take care of, > > since it should build in parallel only the targets independent > > of each other. > > If (as I said) you impose the correct dependency information. > Currently there is no such information provided. Ah, so we don't have any reliable information about dependencies between the ports either (not just between files inside each particular port)? Hm, I think it would present a problem even when building them sequentially. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: speed up port compiling using RAM (tmpfs) ???
Kris Kennaway wrote: > > On Fri, Jan 20, 2006 at 11:25:33AM -0600, Sergey Babkin wrote: > > >From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]> > > > > >Gary Thorpe <[EMAIL PROTECTED]> writes: > > >> This effectively means that you cannot take advantage of SMP to > > >> compile FreeBSD's ports collection. That sounds like a big > > >> limitation...especially for people trying to speed up bulk builds. > > > > > >We cannot be held responsible for race conditions in the Makefiles of > > >third-party software. > > > > Well, maybe we can then build multiple ports in parallel. > > I guess the way to do it would be to run the top-level make with > > -j but then disable it when calling the makefiles of the > > individual ports. Not that I have any idea how to actually > > do that. > > It's harder than that, because you need to impose dependency > information and mutual exclusion between different makes. e.g. they > can't both be compiling the same port at the same time, which will > happen if you just do the naive thing. That's the part that "make -j" is supposed to take care of, since it should build in parallel only the targets independent of each other. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: speed up port compiling using RAM (tmpfs) ???
>From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]> >Gary Thorpe <[EMAIL PROTECTED]> writes: >> This effectively means that you cannot take advantage of SMP to >> compile FreeBSD's ports collection. That sounds like a big >> limitation...especially for people trying to speed up bulk builds. > >We cannot be held responsible for race conditions in the Makefiles of >third-party software. Well, maybe we can then build multiple ports in parallel. I guess the way to do it would be to run the top-level make with -j but then disable it when calling the makefiles of the individual ports. Not that I have any idea how to actually do that. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My wish list for 6.1
Kris Kennaway wrote: > > On Fri, Dec 16, 2005 at 10:34:09PM -0800, Avleen Vig wrote: > > On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: > > > > 2. SMP kernels for install. Right now we only install a UP kernel, for > > > > performance reasons. We should be able to package both a UP and SMP > > > > kernel into the release bits, and have sysinstall install both. It > > > > should also select the correct one for the target system and make that > > > > the default on boot. > > > > > > If people are concerned about performance, I benchmarked a 6-beta > > > kernel SMP versus UP on a socket 939 Opteron. > > > > If those results are accurate, there's no real reason not to just use an > > SMP kernel on default install? > > Just because it didn't manifest on this workload, doesn't mean it > doesn't on others. I think this is the point :) Hm, how about this (similar to what Linuxes do): Use an SMP kernel for the installation boot, so that the install scripts can discover the SMP machines. Have two GENERIC kernels built and packaged, UP and SMP. The install scripts then install the kernel matching the absent or present SMP (like Linux distros do). Probably with an option of a manual override through a menu. Maybe better yet, install both (or allow to install both) and allow to choose the one booted through a sysinstall menu. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem booting FreeBSD from cboot FreeBSD from cdrom using grubdrom using g
>From: Tony <[EMAIL PROTECTED]> > I'm trying to make an iso image that will boot FreeBSD using GRUB boot >loader. > >Then the kernel starts, but when the kernel try to mount the root fs, it >stops. I have the follow line in my /etc/fstab >/dev/acd0c / cd9660 ro 0 0 > >I am stranded. Can anyone help? I'm using FreeBSD 5.4 A real stupid question: do you have the cdfs statically linked in your kernel? Do you have the kernel configured to used the cdfs type for the root filesystem? -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: sysctl, HW_PHYSMEM, and crippled gcc
>From: Divacky Roman <[EMAIL PROTECTED]>
>On Thu, Dec 08, 2005 at 05:06:16PM -0800, Steve Kargl wrote:
>> Anyone have any insight into fixing gcc to make better
>> use of system memory on systems with more than 4 GB.
>> It appears that libiberty/physmem.c tries to use sysctl()
>> to determine the amount of physical memory in a system.
>>
>> { /* This works on *bsd and darwin. */
>> unsigned int physmem;
>> size_t len = sizeof physmem;
>> static int mib[2] = { CTL_HW, HW_PHYSMEM };
>>
>> if (sysctl (mib, ARRAY_SIZE (mib), &physmem, &len, NULL, 0) == 0
>> && len == sizeof (physmem))
>> return (double) physmem;
>> }
>>
>> This works if you have less than 4GB because of the unsigned
>> int physmem. I have 12 GB, which of course, when expanded
>> to the number of bytes doesn't fit into a unsigned int physmem.
>> In particular, ggc-min-heapsize=4096 is ridiculously small for a
>> system with 12 GB of memory.
>
>the code works here (512M of memory)... dont know about the ifdefs its
>surrounded by..
I guess you've confused M and G :-) The point is that
it breaks with over 4G of memory.
-SB
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: SSH From within a Jail
>From: Pawel Jakub Dawidek <[EMAIL PROTECTED]> >On Sun, Nov 13, 2005 at 09:26:05PM +0100, Koen Martens wrote: >+> Just remembered something else: do you jexec into the jail, or do >+> you do a proper logon (eg. ssh into the jail). I think that if you >+> jexec into the jail and then try to ssh, you might have a problem >+> because you aren't really logged in to the jail and thus have no >+> (psuedo) tty associated with your session.. > >I just saw this thread. Yes, you are right, I can confirm this. >To be able to ssh to another server from within a jail, you need to >log in to the jail properly (have access to your terminal), so >jexec won't work here. >Try to ssh into the jail and then ssh to another box. "ssh -n" can work without a tty. Though I'm not sure what was the question, I did not watch this thread from the start. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: GEOM for multipath? How?
>From: Danny Howard <[EMAIL PROTECTED]> >Hey ... yes, I recall there being issues with the QLogic drivers ... I >wonder if anyone has given the mpt drivers a shot? I was able to speak >with an engineer at Engenio (now owned by LSI) and she said there were >some issues with the QLogic dual-port cards that were interesting to >her, but the LSI dual-port cards behaved differently ... QLogic worked fine in multi-path configuration with UnixWare. I think LSI and Adaptec did too. The only trick is to make sure that the IRQs of the cards are not shared between the cards or with any other device. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: allocating 14KB memory per packet compression/decompression results in v
>From: Giorgos Keramidas <[EMAIL PROTECTED]> >On 2005-11-03 22:56, kamal kc <[EMAIL PROTECTED]> wrote: >> since i am using the adaptive LZW compression scheme it >> requires construction of string table for >> compression/decompression. So an ip packet of size 1500 bytes >> requires a table of size (4KB + 4KB + 2KB = 12KB). > >I may be stating the obvious or something totally wrong, but >couldn't the string table be constructed once instead of each >time a packet goes down? It is my intuition that this would >perform much much better than re-doing the work of the string >table each time a packet goes out. No, the table changes as data is compressed. It records the knowledge about the strings that have already occured in the data. Keeping the table between the packets would improve the compression but the packets would have to be transmitted through a reliable medium since to decompress a packet you would have to decompress all the preceding packets first (essentially you get a stream compression). To keep the packets separate, the compression state must be reset between them. But of course resetting the compression state does not mean that the memory should be deallocated. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: allocating 14KB memory per packet compression/decompression results in v
>From: kamal kc <[EMAIL PROTECTED]> >since i am using the adaptive LZW >compression scheme it requires construction of string >table for compression/decompression. So an ip packet > of size 1500 bytes requires a table of size (4KB + > 4KB + 2KB =12KB). > >further still i copy the ip packet > data in another data buffer (about 1.4KB) and >then compress it. > >So all this adds up to about 14KB. > >Right now i can't do with less than 14KB. > >as i said before the compression/decompression works >fine. but soon the kernel would panic with one >of the vm_fault: error message. Most likely you overrun your buffer somewhere and damage some unrelated memory area. >what would be the best possible way to >allocate/deallocate 14KB memory per packet without >causing vm_faults ?? The best possible way is to not do it at all. Allocate you 14KB buffer once and then reuse it for every packet. Obviously, your code would have to be either single-threaded, or synchronize the access to the buffer, or use a separate buffer per CPU. >is there anything i am missing ?? Also an extra memory-to-memory copy is a bad idea. It hurts the performance. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: locking in a device driver
>From: "M. Warner Losh" <[EMAIL PROTECTED]> >Scott Long <[EMAIL PROTECTED]> writes: >: Dinesh Nair wrote: >: > >: > >: > On 11/03/05 03:12 Warner Losh said the following: >: > >: >> Yes. if you tsleep with signals enabled, the periodic timer will go >: >> off, and you'll return early. This typically isn't what you want >: >> either. >: > >: > >: > looks like i've got a lot of work to do, poring thru all the ioctls for >: > the device and trying to use another method to wait instead of tsleep(). >: >: Note that a thread can block on select/poll in 4.x and still allow other >: threads to run. I used this to solve a very similar problem to your in >: a 4.x app of mine. I have the app thread wait on select() on the device >: node for the driver. When the driver gets to a state when an ioctl >: won't block (like data being available to read), then it does the >: appropriate magic in it's d_poll method. select in userland sees this, >: allows the thread to resume running, and the thread then calls ioctl. >: Of course you have to be careful that you don't have multiple threads >: competing for the same data or that the data won't somehow disappear >: before the ioctl call runs. But it does work. Look at the aac(4) >: driver for my example of this. > >Yes. If you have the ability to know that an ioctl won't block before >you call it, that would work too. This method is a little trickier, >like you say, but can be made to work. I've also seen ioctls that Maybe it can be fixed in the kernel without too much trouble. Basically, the trick would be to start another kernel thread when the first one blocks. Then the original one can be left executing the ioctl while the new one continues the work. Then of cours ethere should be some notification mechanism that the ioctl has completed. The new thread can start in a signal handler, kind of like what UnixWare does (and I believe Solaris too): they have an M:N model where M user threads are scheduled on N kernel threads. When all the kernel threads of a process get blocked, a signal is sent thread which handler then starts a new kernel thread if there are any runnable user threads. Hm, suppose we have a per-process property "is threaded" that would be set by the threads library. Any blocking calls (tsleep() and such) would check it, and if it's set than immediately post this "all threads are blocked" signal. Then the library can catch it and handle in some useful way, maybe doing an rfork() or just running another user thread and returning to this one later. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: how to make the FreeBSD 6.0 run faster
>From: Robert Watson <[EMAIL PROTECTED]> >On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > >> How do u disable malloc debugging flags in the userland? I read >> somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. >> How does it work? >> >> And how to disable verbose features in the kernel? >> >> Apart from this, are there other ways to make the kernel run faster?? > >Other than that, you'll need to tell us what you're doing. And the most important part: try to optimize your application first. I've seen a surprizing number of people who feel that they need to do something with the kernel while what is really suboptimal (or downright broken) is their application. When writing programs people make many assumptions about what is fast and often these assumptions are wrong, plus there are bugs where the code generally works but does it slowly. This is especially true for applications written in C++ and other OO languages, and for threaded applications. If you want to have a cost-efficient solution, the applications really need to be profiled and measured, and all the performance squeezed out of them before going into the kernel. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB mouse problem
>I do have the mouse working, but with a couple of issues. The main problem >seems to be that the last 3 bytes of the sc_data seem to be wrong. Their >values never change from the time that the device is attached. They're usually >all 0, but sometimes have values. The forth byte is supposed to hold the Z >axis, but I never get any Z axis data, at all (except for the possible random >value in the forth byte previously mentioned). When I move the scroll wheel, >I get a lot of events, but the data is all zeros, except, possibly, for the >last 3 bytes, which have the same values as before. First, a disclaimer: I haven't looked at the FreeBSD USB mouse driver and can't tell if what I say is truly relevant. But, it looks to me like it does not use the HID descriptor. The other possibility is that the HID descriptor in your device is wrong (as in "a firmware bug"). What the HID descriptor is: The USB spec is very clever, and requires that the normal USB devices provide not only the data itself by also the descriptor tables describing the meaning of the data - which fields are where and how they are formatted. Or at least it requires that for the Human Interface Devices (HID). The descriptors are stored in ROM inside the device and are sent to the computer on request. The exact formatting of the descriptors is complicated but in essence it boils down to the triplets of (meaning, location, format). There are pre-defined standardized tables of possible meanings (functions) and the codes associated with them. For the mouse the functions would be such as "X axis movement", "Y axis movement", "Button 1", "Button 2", "Button 3" etc. These tables are hierarchical: i.e. some meanings are applicable to any HID devices, some for any kind of pointer device, some specifically for mice. Of course the manufacturer includes only those meanings in the descriptor that are actually supported by the device. Then again the manufacturer is free to include any extra device-specific information that is not described by the descriptor. To use this device-specific information a device- specific driver would have to be used. On the other hand, a generic driver can be used with any device that provides a suitable descriptor with needed functions. So how a generic mouse drived should work: when writing the driver its author looks up the codes for all the related functions in the manual. Then when a mouse is connected, the driver should query its descriptor, and then go through it and find the information about these functions and remember it. Then when it receives the data from the device, it should look for data in it according to what it has found in the descriptor. And similarly for constructing messages to be sent to the device. >From your description it looks like the present driver does not go into all this trouble but instead assumes a particular hardcoded format of incoming data. But again, I might be wrong. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB mouse problem
>I do have the mouse working, but with a couple of issues. The main problem >seems to be that the last 3 bytes of the sc_data seem to be wrong. Their >values never change from the time that the device is attached. They're usually >all 0, but sometimes have values. The forth byte is supposed to hold the Z >axis, but I never get any Z axis data, at all (except for the possible random >value in the forth byte previously mentioned). When I move the scroll wheel, >I get a lot of events, but the data is all zeros, except, possibly, for the >last 3 bytes, which have the same values as before. First, a disclaimer: I haven't looked at the FreeBSD USB mouse driver and can't tell if what I say is truly relevant. But, it looks to me like it does not use the HID descriptor. The other possibility is that the HID descriptor in your device is wrong (as in "a firmware bug"). What the HID descriptor is: The USB spec is very clever, and requires that the normal USB devices provide not only the data itself by also the descriptor tables describing the meaning of the data - which fields are where and how they are formatted. Or at least it requires that for the Human Interface Devices (HID). The descriptors are stored in ROM inside the device and are sent to the computer on request. The exact formatting of the descriptors is complicated but in essence it boils down to the triplets of (meaning, location, format). There are pre-defined standardized tables of possible meanings (functions) and the codes associated with them. For the mouse the functions would be such as "X axis movement", "Y axis movement", "Button 1", "Button 2", "Button 3" etc. These tables are hierarchical: i.e. some meanings are applicable to any HID devices, some for any kind of pointer device, some specifically for mice. Of course the manufacturer includes only those meanings in the descriptor that are actually supported by the device. Then again the manufacturer is free to include any extra device-specific information that is not described by the descriptor. To use this device-specific information a device- specific driver would have to be used. On the other hand, a generic driver can be used with any device that provides a suitable descriptor with needed functions. So how a generic mouse drived should work: when writing the driver its author looks up the codes for all the related functions in the manual. Then when a mouse is connected, the driver should query its descriptor, and then go through it and find the information about these functions and remember it. Then when it receives the data from the device, it should look for data in it according to what it has found in the descriptor. And similarly for constructing messages to be sent to the device. >From your description it looks like the present driver does not go into all this trouble but instead assumes a particular hardcoded format of incoming data. But again, I might be wrong. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help regarding : To recieve and tranmit packet th' an interface
>From: rashmi ns <[EMAIL PROTECTED]> >Hello List-members, >we are writing a driver for HDLC-Controller We have coded upto some extent >and actully we are able to transmit and recieve a char buff in loopback >(from inside a driver). >But we want to tranmit/Rx a real packet in (mbuf structure) and test our >code .As it is a HDLC controller does'nt have std MAC ADDRRSS . How can i >actually achieve a packet transmition and reception .Are there some drivers >which does the same All the point-to-point interfaces don't have a MAC address. You don't need it since there is only one place to which you can write data, into the port. Well, the problems start when you want to establish X.25 connections. Then you use the X.25 address similarly to a MAC address. But since usually the X.25 connections are static, you set up your table of connections and the translation table between the target IP address and X.25 address, similar to ARP but static. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: system password's file
>On Fri, 14 Oct 2005 [EMAIL PROTECTED] wrote: > >> I want to migrate from linux to freebsd. My linux box (mail server) have >> alot of user (hundreds) --this is the problem. I dont know which file >> which the password's file. I dont want typing user name and its password >> one by one. Beside of that, thereis possibly my users change their >> passwords. How can I do this migrating ? (save) I'm sorry my English is >> not good. > >The main man page you want to look at is passwd(5), which documents the >formats of the /etc/master.passwd and /etc/passwd file. In FreeBSD, the >master.passwd file is the equivilent of the shadow file in Linux. What >you want to do is convert the Linux password files to the master.passwd >file in FreeBSD, and then run Historically the problem has been that FreeBSD used its own MD5 algorithm for encrypting the passwords which was incompatible with any other Unix, so just copying the password field to FreeBSD did not work. I don't know if it's fixed now or not. The reason for that was in the US cryptography export regulations, and those have been improved in the last few years. In any case, even if it's not directly supported then probably a PAM module can still be written. Hm, considering the we'd like people to migrate from Linux to FreeBSD, having such a conversion script/program (especially if someone writes it for their own use anyway) in the base system would make a lot of sense. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Driver Development Books?
>From: Pete <[EMAIL PROTECTED]> >Date: Tue Oct 11 11:47:28 CDT 2005 >To: freebsd-hackers@freebsd.org >Subject: Driver Development Books? >Hello, >I have what may seem to be a silly question, but I cannot find any >other decent resources on the web. >.< The problem that I am having >right now is >that I have a fairly nice graphics card which, for the moment is only >supported on Windows Operating systems, and old 2.4 Linux kernels. So >far there has >not been much positive outlook in porting the drivers to *BSD or any of >the 2.6 kernels that I know of, let alone 64-bit drivers for non-Win OSes. The video cards usually have nothing to do with the kernel itself. Their drivers are in the X Window system. Probably the easiest fix is to just install an older version (3.x probably) of XFree86 on your machine. >So I guess that makes my question fairly simple then; I know that driver >code is written in C (which I am learning currently) but thats about all Well, you usually need a bit more expertise than "learning currently" to write drivers. >I know. I'm probably >not far off when I say that I need more to go on. Yet, from looking at >Amazon.com I have not been able to find any books on writing driver >code, which is really >frustrating. Searching for "device driver" turns up a lot of books on Amazon. For the system-specific details look in the online FreeBSD Device Driver Writer's guide (part of the Handbook if I remember correctly). Anyway, for the graphical cards it's not what you need. The graphical drivers are running in user space as a part of X server. Writing them is a completely different story and I don't think there are any manuals. Just look at the code of the other drivers and do the same. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: serial login to SBC
>From: "M. Warner Losh" <[EMAIL PROTECTED]> >In message: <[EMAIL PROTECTED]> >Brian Reichert <[EMAIL PROTECTED]> writes: >: On Fri, Sep 30, 2005 at 05:14:01PM +0200, [EMAIL PROTECTED] wrote: >: > >: > Hello list, >: > I am trying to use a FreeBSD box to log into a Single Board Computer. I >: > have a null modem and it's plugged to both serial >: > ports. The SBC runs openbsd ( /dev/cua00). >: > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login >: > prompt. >: >: Do you have getty running on that port on the SBC? > >Do you have all the modem pins connected for this cable? Also, is the cable pin-out correct even for the Rx and Tx pins? There are weird recombinations of male-female and DCE-DTE pin-out used by different manufacturers. The easiest way to check is to get a port tester (a pass-through BOX with LEDs) from some place like Radioshack. The correct Unix cable connection is Tx - Rx DTR - DSR, CD CTS - RTS (and the other side symmetric). Many cable manufacturers use different (wrong) connections. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: JFS2 on freebsd
>From: Mike Silbersack <[EMAIL PROTECTED]> > >On Fri, 9 Sep 2005, Kamal R. Prasad wrote: > >> would a port of JFS2 be of interest to freebsd core? >> thanks >> -kamal > >There are many things that would be of interest to FreeBSD users, but >that's not a good reason to start a project. If you're motivated only >because you think others desire your work, you'll probably give up when >you have to start dealing with all the realities of the project. However, >if you're motivated because *you* want to port JFS2, then you'll probably >do a good job of it. > >So, of course support for new filesystem support is good, but my personal >opinion is that JFS2 isn't worth your time, for two reasons: > >a) Even if it's BSD licensed, it's unlikely to displace UFS as our >default filesystem. > >b) It's not a widely used filesystem, so it doesn't really increase our >interoperability with other OSes. > >OTOH, updating our ext2 code, or ntfs code (if that's even possible) would >be something of use to many people, I suspect. Why not go for ext3 instead of JFS then? It has journaling in it. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS hanging
>From: Steve Suhre <[EMAIL PROTECTED]> > >I know I've dealt with this before...but can't remember what the deal >was... I mount a remote server to /mnt and the mount command seems to >work, no errors or logged errors on either machine. But when I try to cd >to the /mnt folder on the client the server hangs. I can't do an ls >without it hanging either. I can't even kill the ls process, the client >needs to be rebooted to clear any hung commands. The client is running >an older version of bsd (BSDI), the nfs server FreeBSD 5.4. Any help >would be appreciated. Looks like the mountd daemon on the server is working fine but nfsd is not. Check if it's running, if the versions are matching, and such. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: vn_fullpath() again
>From: Giorgos Keramidas <[EMAIL PROTECTED]> >On 2005-09-06 19:27, Igor Shmukler <[EMAIL PROTECTED]> wrote: >> Perhaps, I do not get it or maybe you are do not getting my point. >> >> There are times when resolving would not be possible or a name returned is >> not necessarily the one used when file was first accessed. We have discussed >> it here and everyone agreed on that. The hardlinks or files unlinked while >> vnode is still open are corner cases. The unlink is a bit more difficult to >> deal with, but hardlinks are probably not a big issue. As long as we can get >> A name, we may not even need to know THE name. > >Why does it make sense to get name A in the following scenario then? > > user 1 creates file A > user 1 hardlinks this to B > user 1 gets the "real name" of A > user 2 deletes file A > user 2 creates a new file called A > user 1 tries to access A and gets something unexpected > >Corner cases and their handling *is* important. Find another way to do >whatever it is you're thinking you can do with "the real name of a vnode". This particular case is easy to handle: all that user 1 needs to do is to do fstat() after opening the file and check that the returned inode field is still the same. On the otehr hand, if there is this new interface to access files directly by inode numbers, why bother with any names at all? If a name is so desirable, then just create a pseudo-fs translation that would convert the text-formatted device and inode number given to it as a file name to an access to the identified file. Though both this and access directly by vnode number open a security hole: in many cases the access to files mught be actually limited by making the directories unreadable to the unwanted users. Bypassing the directories bypasses this "security by obscurity". -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: nagios and freebsd threads issue : help please ...
>> > This is funny, because nagios apparently runs properly on Linux, HPUX, >> > Solaris, Irix, AIX and Tru64. To me that seems to indicate that Nagios This does not neccessary mean that it _really_ works. There might be a race involved that usually ends up lucky on these systems. >> > is very portable indeed and that the BSD fellows somehow botched it. I >> > might be wrong, but... >> >> Just because it works doesn't make it standards conforming. >> >> Maybe there's some simple extension that can be implemented to help >> the situation. > >It seems the main problem of the Nagios developper seems to be they >would need to rewrite a big part of their current implementation. >I'm not sure however this is mandatory. I wonder if the so-told >pthread_atfork() handler wouldn't be a quick solution to address the >problem. Sorry if it's dumb. I'd even say that it's the proper correct solution. This probably should me made a part of "how to write thread-safe libraries": register pthread_atfork() function that would free every possible mutex and conditional in the library. And clean up the other state too. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: region code in cdrecord
>(like I said, but in roundabout fashion I admit) region 2, so suggesting >that I ignore the region is silly, it's there already. My dvd (and that >of my friend's, I tested) both immediately choke on trying to play this Sorry, can't help with your original question, but I can help with the choice of DVD players. Phillips makes a good reprogrammable one. I think the model is called 642 in US and 630 in Europe, I can look at mine (US) at home. Walmart and Target sell them for shomething like $70. Changing the region code is a breese - you get the tray open, press the "secret" button sequence and can enter the new code. Setting the code to 0 would make it region-free and would play any disks except the very paranoid ones. For those you can change it back to 1 or 2. >disk, they don't even open a menu. I need to change that encoded region >value from 2 to 1. Having software here that coded, say, a null value AFAIK it's done in a more interesting way: the region code on CD is actually a small interpreted bytecode program that reads the player's configuration data with the region code in it and decides if it wants to play on this player or not. That's why some disks won't work with the players having region 0. I'd guess that this program can be happily amputated altogether. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
mohamed aslan wrote: > > guys this is not a flame war > but the linux way in arranging the source file is really better than > freebsd way, it's a fact. Nope. It's real difficult to organize the files worse than in Linux. FreeBSD is actually real good. Way better than UnixWare, and of course anything beats Linux with its crazy patchwork. > primary os. but we can get the good things from linux and through out > the bad ones. Yes, procfs rules! -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIC 1 gigabit
[EMAIL PROTECTED] wrote: > > Hi, I have trouble with my NIC. > I'm using Server Mainboard Intel (I forgot the model), there is 2 NICs; the > one > is 100Mbps other is 1 gigabit. I use this for my web server with freeBSD > 5.1-RELEASE. > NIC 1 gigabit is not detected and recognised neither by freeBSD the other is > fine and working. > What should I do ? Should I recompile kernel ? And How ? > Sorry, my English is bad. Intel is known to change the PCI IDs of the cards pretty often, so the older drivers won't recognise the newer compatible cards as such. Get a newer version of FreeBSD that has the updated ID table in the driver. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
Doug Russell wrote: > > On Thu, 7 Oct 2004, John Von Essen wrote: > > > Well, I eventually got this SCO system working. But today, some errors > > appeared: > > > > 505k:unrecover error reading SCSI disk on 0 Dev - 1/42 > > cha = 0 id = 0 1 on = 0 > > Block 6578 > > medium error unrecovered read error > > HTFS i/o failure occurred while trying to upgrade 1 node 26302 on > > HTFS. Dev hd 1/42 > > Error log over flow block 6578 medium error unrecovered read error . > > > > Do these sound likes hardware errors for the drive or the adaptec card > > Drive errors. > Did you do a new low-level format before you put it in service? > > sformat is your friend. Try to use the "Verify" menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). > I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. -SB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Discussion on the future of floppies in 5.x and 6.x
Leo Bicknell wrote: > > I'm going to propose a different solution that was brought up about > two years ago (although I can't find it now). > > You start with something like the CD boot image mentioned, that is > a 3-5 Meg iso image that basically contains what is now on the > floppies (perhaps with a few more drivers/modules) and nothing more. > Downloading and burning to CD would be the primary method of install. > > Then, to replace the current floppy process, a new floppy installer > is created. It may or may not be based on FreeBSD, but what it I guess a simple variation would be to split the CD boot filesystem into multiple floppies. Then remove the current contents from the MFSROOT floppy and put there a small program (plus possibly the first part of the split CD filesystem image) that would load the boot filesystem from the bunch of floppies into memory, load the extra kernel modules, and then start the installer from memory just as it would go when booted from CD. That should really be a no-brainer as long as the base kernel still fits onto one floppy. The only inconvenience is that we get something like 6 install floppies instead of 2, but it's not _such_ a big deal. -SB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: has anyone installed 5.1 from a SCSI CD?
Peter Jeremy wrote: > > On Sun, Sep 28, 2003 at 06:14:25PM -0400, Sergey Babkin wrote: > >BTW, I have another related issue too: since at least 4.7 > >all the disk device nodes have charcater device entries in /dev. > > As of December 1999 - which is before 4.0-RELEASE. This was well > advertised and discussed at the time. Your objections are about > 4 years too late. Well, the previous version I installed was 4.0-snapshot that did not have this change yet. Also it's never too late to fix the broken things. > >That's very, very wrong. Even though there may be no difference > >any more between the charcater and block drivers, the type of > >device node still conveys the information about device types > >to the applications. One case in point being a viewer application > >(if anyone is interested, http://nac.sf.net ) which must handle > >the sequential and random-access devices differently: > > 'block' vs 'character' has nothing to do with random or sequential > access and any application that thinks it does is broken. Any > application that directly accesses devices must understand all the > various quirks - ability to seek, block size(s) supported, side- The random-access devices are seekable by definition. And the OS interface is there to hide the block size issues. > The only purpose for block devices was to provide a cache for disk > devices. It makes far more sense for this caching to be tightly > coupled into the filesystem code where the cache characteristics > can be better controlled. What I'm saying is that it's good to have an easy way for applications to distinguish the random-access devices from the sequential-only-acces devices. Are they cacned internally or not is not that much of an application's concern. -SB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
has anyone installed 5.1 from a SCSI CD?
Hi all, I've got the compiler on my -current partition hosed (I did a make install at a time when it was unstable, and now it dies when recompiling -current), so I decided to re-base it with 5.1. That's when I discovered an unpleasent issue: it could not mount SCSI CD-ROM! The devices (I have two of them) show up fine in dmesg and the entries in /dev are created fine but then when I try to mount it, it says that the operation is not supported by the device! Huh? Someone has been playing too much with the CD driver. BTW, I have another related issue too: since at least 4.7 all the disk device nodes have charcater device entries in /dev. That's very, very wrong. Even though there may be no difference any more between the charcater and block drivers, the type of device node still conveys the information about device types to the applications. One case in point being a viewer application (if anyone is interested, http://nac.sf.net ) which must handle the sequential and random-access devices differently: for the random-access device it can page in the data for viewing on demand (and discard when some part is not viewed, since it can be read again easily), with possibility to jump to a random address, while for a sequential device it must read the data sequentially to a local buffer and never discard data from that buffer. It works fine on every system except the recent FreeBSD :-( -SB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: making CVS more convenient
Terry Lambert wrote: > > Sergey Babkin wrote: > > Terry Lambert wrote: > > > > # OK, let's suppose that our changes are finally complete, and nobody > > > > # else has committed any other changes in between > > > > cvs ci > > > > > > Suppose someone has? If you are so out of touch with the net you > > > need a cache, you are probably going to get a conflict, because > > > > It's very likely that the conflict can be cured by a simple > > "cvs update". > > How? Your local repository is out of date. You can't update > your local repository because it's a cache, and the cache contains > some local changes, and any update will bow those changes away, or > abort because there's a conflict. This is exactly my "incoherent" > picture. No, it does not contain the local changes. The local changes are in a completely separate repository. (Well, if the same repository could be made to contain the local changes without upsetting cvsup and cvs, that would be just as good or better. But that seems to be too difficult, a completely separate repository for local changes looks easier). Hope that clarifies the picture. > You can't make local checkins to the same place CVSup writes to; > CVS is too stupid, and CVSup is too stupid to handle it. You'd > need a "multicvs" -- one that could operate a shadow repository. Yes. I guess we just had terminological difficulties with explaining this point to each other :-) -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Terry Lambert wrote: > > Sergey Babkin wrote: > > # OK, let's suppose that our changes are finally complete, and nobody > > # else has committed any other changes in between > > cvs ci > > Suppose someone has? If you are so out of touch with the net you > need a cache, you are probably going to get a conflict, because It's very likely that the conflict can be cured by a simple "cvs update". > > So pretty much all I want is to make this procedure a bit more > > convenient, able to handle whole subdirectories as opposed > > to separate files. > > That's reasonable, but... you're rcs ci is a killer; it assumes > a local repostory in parallel. I guess you want a "multicvs", > which does checkins remotely or locally? I'm not sure what is a "multicvs", I just want to have some storage for the data before I get to commit it to the real repository. For example, suppose I write some code. Then I run a test on it and find some deficency that needs a non-obvious fix. At this point I want to save the present version somewhere before I start doing the fix, to make sure that I at least won't make things worse, and if I make them worse then I can always return back. After the fix is done and the test runs successfully, the final result can be committed to the central repository. > > As a model consider this: suppose we build a separate copy of the CVS > > binary, called "mycvs" that has the following differences from > > the normal CVS: > > That's actually grosser than the rcs version (IMO)... It's only an example to show an analogy. Though after thinking about it, it looks like a good model to start with and cover under the hood of cvs commands. > > > of verbatim copying of the repository. > > > > > > Incoherent: > > [ ... diagram ... ] > > > Why is it incoherent ? CVS checks that the version obtained by "cvs co" > > and then modified is still the top of the tree. If it's not, > > it will refuse to commit and will request you to do an update. > > I left out the (I thought) obvious part; ket me fix it: > > ,---.-cvsup(1)->,---. > | Main | cvsup(2)->| Cache |<--. > | Repo |[CONFLICT] | Repo | | > `---' `---' | > ^ | | > |cvs co | > cvs ci(2) | cvs ci(1) > [CONFLICT] V | > cvs ci(3) ,---. | > | | Work | | > `---| Copy |---' > `---' > > Order: > cvsup(1) > cvs co > cvs ci(1) > cvs ci(2) [CONFLICT] > [FIX] cvs ci(3) > cvsup(2) [CONFLICT] > > In other words, you can't order commits with conflicts, without > going to the main repo first in call cases. That destroys your > intended disconnected use. When cvs ci(2) finds a conflict, the master repository is left unchanged. So cvsup will never see any conflicts. The real sequence would be cvsup(1) cvs co cvs ci(1) cvs ci(2) [CONFLICT - check-in fails] cvsup(2) cvs update [hopefully update resolves the conflict, or fix it manually] cvs ci(3) > The first time you get a conflict, your MYCVSROOT repository > is blown, and you won't be able to resyncronize it, without > replacing ",v" and "CVS/*" file contents. No. Two repositories in this example are completely independent. Their only connection is by checking in and out the same file manually. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Nate Williams wrote: > > > It gets handled in the same way as now: I believe, CVS checks > > whether the checked-out version matches the top of the branch, > > and if it does not then it refuses to commit and requires you > > to make an update. So the same thing can be done for a "local branch": > > check that its base version is still the top of the real branch, > > and if so then commit. Otherwise require an update/merge. > > Except that it's possible that the 'local' cache is out-of-date > w/respect to the remote repository, say if someone made a commit to it > since the last 'synchronization' of the local cache. > > You don't want that commit to happen, since it should be allowed because > the file is really not up-to-date w/respect to the master. The worst > case is the committed change would conflict with the as-yet-unseen > change on the master, so allowing the local user to commit it means that > when the 'cache' attempts to commit it later, it will fail, and the > 'cache code' is required to figure out how to extract the commit from > the local cache, update the local cache, re-apply the (now conflicing) > commit back to the local cache and somehow inform the user at a later > point. > > *UGH* Yes, this is way too complicated and error-prone. This is why I don't want to change the cache without changing the master in the same way first. > > > If you only allow the commit if it can occur locally, you're ensuring > > > that the cache can't get out of date with local changes. I tried > > > something like the above (cause it was easier to implement), and it > > > worked most of the time. However, the times it didn't work it was a > > > royal pain in the *ss to cleanup and get the original commit back out. > > > > Maybe I just was not clear: I think that making the commits in the > > local copy on the real top of the tree is a quite bad idea. > > I think it's a good idea *IF and only IF* the commit to the remote tree > works. That way, the local user isn't required to re-synchronize his > cached tree agains the master tree, since their is a high liklihood that Agreed. So the commit would essentially work as a commit plus resynchronization of a subset of files in the cache. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Terry Lambert wrote: > > Sergey Babkin wrote: > > Nate Williams wrote: > > [ ... "CVS cache and cache coherency" ... ] > > > Yet another idea is to be able to make "local commits" with committing > > them to the central remote repository later. Now I have to use RCS > > locally for the temporary in-delevopment versions of file. Would > > be nice to have a kind of a local branch which can be later committed > > as a whole - in one commit per file, or by duplicating all the > > intermediate versions with their messages. > > Not really possible, without CVSup coming onto a vendor branch instead Actually, I was thinking of the opposite: doing all the changes on a vendor branch (or in some separate local repository altogether), then merging them into the main branch. Think of the following sequence that can be used now: cvs co rcs ci # save the baseline #... some modifications done rcs ci #... more modifications rcs ci # then someone committed another change to the repository and we want # to merge that change in cvs update # do the manual merge if neccessary rcs ci # save the merged version #... more modifications rcs ci # OK, let's suppose that our changes are finally complete, and nobody # else has committed any other changes in between cvs ci So pretty much all I want is to make this procedure a bit more convenient, able to handle whole subdirectories as opposed to separate files. As a model consider this: suppose we build a separate copy of the CVS binary, called "mycvs" that has the following differences from the normal CVS: 1. Instead of the variable CVSROOT it uses MYCVSROOT 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS 3. It never touches any of the keywords (such as $Id etc.) 4. When asked to add a file, it automatically creates the whole path of intermediate directories for it. (How does it know where the checked-out tree starts ? There are many more or less obvious and convenient ways to do that, so let's leave this issue alone for now). Then in the example above you can do export MYCVSROOT=~/tmp/cvsroot mycvs init And do everyhing as in the previous example, only replacing rcs with mycvs (and obviously you wold need to do "mycvs add" before the fiest "mycvs ci"). > of verbatim copying of the repository. > > Incoherent: > > ,---. ,---. > | Main | cvsup --->| Cache | > | Repo | | Repo | > `---' `---' > ^ | > |cvs co > cvs ci | > | V > | ,---. > | | Work | > `---| Copy | > `---' Why is it incoherent ? CVS checks that the version obtained by "cvs co" and then modified is still the top of the tree. If it's not, it will refuse to commit and will request you to do an update. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Dag-Erling SmЬrgrav wrote: > > Sergey Babkin <[EMAIL PROTECTED]> writes: > > A similar thing may be achieved by checking the files out from the local > > repository and doing any modification command with option -d. But that's > > troublesome and inconvenient. > > Read the manual page for the shell you're using, with particular > emphasis on the 'alias' builtin command. I think that it's not a good solution, for several reasons: * Using -d for an alternative repository is pretty much a dirty trick, and undocumented one too. But the purpose itself is quite valid, transparent, and simple and I think that it's better to make it obvious and easy to use than tricky. I like the principle "simple things should be easy, complex things should be possible". * There may be scripts that run cvs commands, which scripts absolutely don't need to know about a cache repository underneath. * I don't like the layers of "workaround scripts" built over other "workaround scripts". I think that it's something of an "aftermarket Unix syndrome": when you can trick a tool to do what you want and wrap it into a script for the ease of use but can't change the tool to do what you need directly, in a simple way. The original Unix (both Bell Labs and BSD) was not like this: when the people made some useful addition, they just got it right into the base system. Now with open source OSes we can do the same thing and not look for extra pain with wrapper scripts. * Getting the cache repository support right into CVS allows to modify the CVS commands in future to take advantage of this knowledge. For example, "commit" may not just check the modification date and send the file to the server if it has changed, but instead also compare the file with the one in the cache repository and send it to the server only if the file has actually changed. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Nate Williams wrote: > > > That's the plan for the next stage, provided that the first stage > > goes well. I'm yet to play with CVSup and see if it can be > > integrated there (as with system()) easily without making a lot > > of changes to CVS itself. Otherwise I'm aftarid it's going to > > be a large amount of work to duplicate this functionality :-( > > Another choice is to have the commit be also made to the 'cache' if and > only if the remote (master) respository has accepted the commit. > > That way, the commit is made in both repositories using the same > algorithm, so in essence they should be in sync. Yes, makes sense. > > Yet another idea is to be able to make "local commits" with committing > > them to the central remote repository later. > > I'd do the reverse, since the possibility of synchronization problems > are a huge deal. Imagine if someone 'snuck' in and made a commit in > the master tree after your local commit was made, but before 'later' > occurred and your cache pushed it out to the master tree. It gets handled in the same way as now: I believe, CVS checks whether the checked-out version matches the top of the branch, and if it does not then it refuses to commit and requires you to make an update. So the same thing can be done for a "local branch": check that its base version is still the top of the real branch, and if so then commit. Otherwise require an update/merge. > If you only allow the commit if it can occur locally, you're ensuring > that the cache can't get out of date with local changes. I tried > something like the above (cause it was easier to implement), and it > worked most of the time. However, the times it didn't work it was a > royal pain in the *ss to cleanup and get the original commit back out. Maybe I just was not clear: I think that making the commits in the local copy on the real top of the tree is a quite bad idea. All I want to get is some temporary versioned storage to play around while I work on the code. After the code gets finished, it gets committed to the master repository just as it committed gets now. > > Now I have to use RCS > > locally for the temporary in-delevopment versions of file. Would > > be nice to have a kind of a local branch which can be later committed > > as a whole - in one commit per file, or by duplicating all the > > intermediate versions with their messages. > > Agreed. The downside to the above method is that it requires network > access to make a commit. However, it certainly simplifies the > problem set. :) :) Well, at least the commit would get done in one batch (of course, unless a conflict happens). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Nate Williams wrote: > > > The value specified in CVSROOTCACHE is the local path to the cache > > repository. All the check-outs, updates, diffs etc. will be obtained > > from there. All the check-ins, tagging etc. will go into the master > > repository specified by CVSROOT. Naturally, to see these changes > > in the cache repository, it needs to be updated by some outside > > means such as CVSup or CTM. > > So, the cache doesn't automagically update itself when commits are done? > This is less useful, since often-times after a commit has been done the > user is still working in the same general area, so a 'cvs update' would > now give the user older files since the read-only cache is not > up-to-date, thus making it a requirement that everytime you make a > commit, you also sychronize the cache. That's the plan for the next stage, provided that the first stage goes well. I'm yet to play with CVSup and see if it can be integrated there (as with system()) easily without making a lot of changes to CVS itself. Otherwise I'm aftarid it's going to be a large amount of work to duplicate this functionality :-( Yet another idea is to be able to make "local commits" with committing them to the central remote repository later. Now I have to use RCS locally for the temporary in-delevopment versions of file. Would be nice to have a kind of a local branch which can be later committed as a whole - in one commit per file, or by duplicating all the intermediate versions with their messages. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
making CVS more convenient
Hi all, I've been planning to send this message to the developers mailing list, but it has mysteriously disappeared (and I haven't found yet its replacement). So here it goes. The idea is to support a "cache" repository (the one copied to a local machine by CVSup or CTM) transparently. So that the reads from directory will go from the local cache repository (and won't overstrain the remote server, and will be fast too), while the commits and other changes will go into the remote master repository. A similar thing may be achieved by checking the files out from the local repository and doing any modification command with option -d. But that's troublesome and inconvenient. This patch allows to deine the following configuration: # so far everything is as usual export CVS_RSH=Hssh1 export [EMAIL PROTECTED]:/home/ncvs # this is new export CVSROOTCACHE=/arch/cacheroot The value specified in CVSROOTCACHE is the local path to the cache repository. All the check-outs, updates, diffs etc. will be obtained from there. All the check-ins, tagging etc. will go into the master repository specified by CVSROOT. Naturally, to see these changes in the cache repository, it needs to be updated by some outside means such as CVSup or CTM. BTW, if there is no chance of conflict between updating the cache directories and check-outs from it, running check-outs with "cvs -r" (read-only repository) will make it faster. The patch (and the same description) are available from http://people.freebsd.org/~babkin/cvs/ (If anyone wonders, yes, I do plan to submit this patch to the CVS people). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing GNU grep with UNIX grep.
"Pedro F. Giffuni" wrote: > > FWIW; > > The UNIX grep executable is like >3 times smaller than > GNU grep but also like 3 times slower. I think that it's said in GNU grep readme: they have knowingly chosen a faster but more memory-consuming algorithm. And I think that they've done similar choices in the other tools as well. After all, we are not limited by a 64KB limit any more, are we ? :-) > Also .. JIC you wonder, I only built this for > curiosity, I recommend keeping GNU grep unless Caldera > changes the license :). Also the GNU grep has a lot more options, the most interesting of them being -r. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Which archiver handles the ICE format?
Dan Nelson wrote: > > In the last episode (Sep 23), Stephen Hocking said: > > I'm wanting to extract data files off the original Quake 1 CD. > > Lets just take a look see... > > All deice does is join the numbered files together, then execute the > result. quake101.1 and quake101.2 are in self-extracting LHA format; > ports/archivers/lha will extract them. If anyone wonders about history, lhice was the previous name of lharc (and was a very good archiver at its time - around 1990). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI device emulation using SCSI host controller
"Kenneth D. Merry" wrote: > > On Tue, Aug 13, 2002 at 21:12:59 -0400, Sergey Babkin wrote: > > "Kenneth D. Merry" wrote: > > > > > > On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > > > > Hi! > > > > > > > > I beg you all pardon for a question not related directly to FreeBSD, but > > > > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > > > > > > > The question is: "Can I emulate a SCSI device (tape, if that matters) > > > > using usual SCSI host controller and specific software, or I will > > > > definitely need specific hardware?" > > > > > > You'll need either the right Adaptec or QLogic controller, but yes, it can > > > be done with FreeBSD. > > > > Or Symbios (now LSI Logic). > > Has anyone done any target mode code for their boards? Not any I know of. If anyone is willing to do that, I can provide examples of the target-mode microcode for Symbios. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI device emulation using SCSI host controller
"Kenneth D. Merry" wrote: > > On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > > Hi! > > > > I beg you all pardon for a question not related directly to FreeBSD, but > > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > > > The question is: "Can I emulate a SCSI device (tape, if that matters) > > using usual SCSI host controller and specific software, or I will > > definitely need specific hardware?" > > You'll need either the right Adaptec or QLogic controller, but yes, it can > be done with FreeBSD. Or Symbios (now LSI Logic). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: termios guru ?
bruno schwander wrote: > > thanks, I see the idea but cfmakeraw has some other effects... newlines > output by the program are not translated, etc. To get rid of the raw output effects, remove the line t->c_oflag &= ~OPOST; > > My main program now is the VMIN/VTIME stuff. The way irit tries to use is, > is basically to be able to do async stdin reading, but this does not > work. Whenever I try those settings, no input is ever read by the > program. It fgetc() constantly returns -1. > > Any idea why ? > > bruno > > On Thu, 11 Jul 2002, Cyrille Lefevre wrote: > > > On Wed, Jul 10, 2002 at 09:13:18PM -0700, bruno schwander wrote: > > > I making a port (not much really) of Irit > > > (http://www.cs.technion.ac.il/~irit/) a modelling environment. > > > > > > I am having some problems with terminal handling, so all termios guru out > > > there, please help ! :-) > > > > > > At stratup, irit does the following > > > > > > Termio.c_cc[VEOF] = 0; /* MIN = 0, no minimal length to wait for. */ > > > Termio.c_cc[VEOL] = 1; /* TIME - 1 tenth of a second as time o > > > > > > which seems wrong, I think it should be > > > > > > Termio.c_cc[VMIN] = 0; /* MIN = 0, no minimal length to wait for. */ > > > Termio.c_cc[VTIME] = 1; /* TIME - 1 tenth of a second as time o > > > > VMIN == VEOF and VTIME == VEOL. On SysV but not guaranteed to be so on every system. In fact, if we look in the FreeBSD /usr/include/sys/termios.h we can see: #define VEOF0 /* ICANON */ #define VEOL1 /* ICANON */ #define VMIN16 /* !ICANON */ #define VTIME 17 /* !ICANON */ No wonder that it does not work. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: offtopic: low level format of IDE drive.
Greg 'groggy' Lehey wrote: > > On Monday, 8 July 2002 at 14:46:29 -0700, Kent Stewart wrote: > > All of the manufacturers have a program that will do that. Many of > > them even produce a bootable floppy. Check their support web page. > > I went looking for format utilities and didn't find anything. Finally > I stuck the disk in an old 486 with a format utility in the BIOS, and > that worked (fortunately the damage was below the 504 MB boundary :-). > > While looking at these format programs, I gained the distinct > impression that they didn't really format. The description was too > vague to make it clear just what they did do, though. Quite possibly > it's the same as dd if=/dev/zero, and it just relocates the logical > sectors. Once in 1996 I had a Western Digital IDE disk that developed bad sectors on it. Rewriting it (doing dd) did not help. The BIOS format did not help. But when I returned this disk to the dealer they ran some low-level format after which the errors were gone and the disk worked happily ever after. So apparently they are not the same. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Terry Lambert wrote: > > Jos Backus wrote: > > On Fri, May 31, 2002 at 01:38:17AM -0700, Terry Lambert wrote: > > > The biggest problem with GNU make that I've seen is re-expansion > > > of variable variables. > > > > > > The suggested fix doesn't address that, so it won't fix the most > > > common "compatability problem". > > > > So what? It fixes (in a backward-compatible way because ``$^'' isn't used in > > BSD make) one incompatibility without which I have to have two different > > Makefiles in the simple case I am thinking about. It's at least an incremental > > improvement that doesn't break anything afaIcs. > > 1) Please see the references I cited. I believe "$^" is used in > a BSD make, even if it's not in the FreeBSD make, and that in > a future version of FreeNSD make, it ought to have the function > of the BSD make that uses it, not GNU make. > > 2) I am not comfortable with changing FreeBSD make into GNU make. I would really like all the existing make branches (BSD, GNU, SVR4) converge to a single syntax. Otherwise it's too much pain, and the only workaround is either to use only the classic V7 make features or write makefiles for gmake since it's readily available on all the platforms. > 3) I am not comfortable adding features to FreeBSD make which > render makefiles, which are then written to use these newly > added features, non-portable to other BSD systems. That's easy: don't write makefiles that use these features. Document them as strongly deprecated and compatibility-only. > 4) There are *already* enough cases where people have written > "sh" scripts with "bash" syntax, so that they *claim* they > are "sh" scripts, but are in fact "bash" scripts. I would > hate to see the same thing happen to "makefiles" to turn > them into "gmakefiles". I agree. If any such additions are made, they should be only enabled by a command-line options. On the other hand, you can just use gmake to the same effect. > 5) What you've added is a synonym for something that's already > there; it is better to change the makefile to use the existing > syntax, then it is to change the "make" to add new syntax. It means changing every makefile. > 6) What are you going to do, when you need to compile on Solaris? SVR4 make extensions are totally incompatible with BSD make extensions, so nothing changes in this respect: the BSD makefiles don't work on SVR4. > 7) What are you going to do when you need to compile on AIX? Same thing. > 8) How is "make" different from "cc" or "tar"? If we are going > to add the features, why not "just use GNU make instead"? Aren't we already using GCC and GNU tar ? Or am I completely missng the point of this point ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
