hello,
just a question on Linux compatibility :
i was told linux binaries that access to the /proc special filesystem won't
work on freebsd ?
is that right for the last release of the linux compatibility package ?
In your opinion, is it possible to trap all these access to /proc ?
the reason why
Egervary Gergely <[EMAIL PROTECTED]> writes:
>> I've just hacked a new ioctl into the ATAPI cdrom driver, which
>> lets the user to specify (pronounce: ``slow down'' :) the speed
>> of todays' extremely high speed drives.
>
>ok, so i see you like the idea - so the question is: should we implement
On 07-Dec-99 Julian Elischer wrote:
> I'm playing with Irda a bit and an wondering if anyone has also been doing
> do. The Linux Irda project lookes quite advanced.
I have been doing not much more than thinking about it :-/
I'd be interested in participating in a project to do IrDA for FreeBS
I'm playing with Irda a bit and an wondering if anyone has also been doing
do. The Linux Irda project lookes quite advanced.
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Mon, 6 Dec 1999, Julian Elischer wrote:
>
>
> On Tue, 7 Dec 1999, Robert Watson wrote:
>
> > On Mon, 6 Dec 1999, Wes Peters wrote:
> >
> > I submitted a pr in June with patches, and it seems to work fairly well.
> > Never checked to see if it was commited though. I've had problems with
>
On Mon, 6 Dec 1999, Julian Elischer wrote:
> On Tue, 7 Dec 1999, Robert Watson wrote:
>
> > On Mon, 6 Dec 1999, Wes Peters wrote:
> >
> > I submitted a pr in June with patches, and it seems to work fairly well.
> > Never checked to see if it was commited though. I've had problems with
> > drop
On Tue, 7 Dec 1999, Robert Watson wrote:
> On Mon, 6 Dec 1999, Wes Peters wrote:
>
> I submitted a pr in June with patches, and it seems to work fairly well.
> Never checked to see if it was commited though. I've had problems with
> dropped packets, however--at certain times of day (?) I can'
On Mon, 6 Dec 1999, Wes Peters wrote:
> Has anyone gotten one of these to work with the lnc driver in current?
> Looking at the chip specs, it is supposed to be software compatible with
> the PCNet PCI parts, but it sports the "home networking" PHY that are
> not supported on other LANCE parts.
>
On 07-Dec-99 Alex wrote:
> in my device driver, that can returns me device
> configuration (pcici_t)? (like in Linux -
> pcibios_find_device)
> Thanks for any help?
Thats not the way its done in FreeBSD..
Your probe routine is called when the system wants to know if a given device
can be
I'm porting the most recent released version of LinuxThreads
(glibc-linuxthreads-2.1.2), and ran into a bit of a problem with regard to
longjmp() and siglongjmp(). LinuxThreads wraps these functions so that
they work correctly in the presence of cleanup handlers. However, this
doesn't appear to
Dear Sir,
I use divert socket to captuer packets. I found that when
I capture a set of fragmented packets, there are 2 incoming reassembled
packets. The sin_port of sockaddr_in of the first packet is 0,
and of another packet is the port number, which it bound to.
However, when the packet i
On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote:
> Software
> is created by humans, and humans are fallible, therefore the software
> is also fallible.
No, that doesn't logically follow. Just because it's possible
for humans to make mistakes doesn't mean that it's impossible to
do or
: I don't maintain -stable's pccard code and to the best of
: my knowledge, no one else does either. This means there is no one to
: look at them.
:
: I'll be happy to look at patches for -stable, however. The times I've
: made this offer in the past I've not gotten patches.
Now that you're vo
I had a similar problem from installing GNU's Portable Threads package.
I fixed it by uninstalling the package.
-Kip
On Mon, 6 Dec 1999, Viren Jain wrote:
> NOTE: Please reply directly to my email address ([EMAIL PROTECTED])
>
> Platform: x86, FreeBSD 3.3
>
> W
This message was sent from Geocrawler.com by "Alex" <[EMAIL PROTECTED]>
Be sure to reply to that address.
Hello,
I'm writting PCI device drivers (KLD) for FreeBSD
3.2.
PCI board is probed and attached correclty during
booting. Is exist any function, which I can use
in my device driver, that c
:> distribute the inodes all over the cylinder group rather then concentrate
:> all the inodes in one place.
:
:Yes. I have implemented most of the code. I noticed the "ls -al" is slow
:but "ls" is OK.
Yes, ls (without any options) is ok because the file type is now being
stuffe
Luoqi Chen writes:
> > I was under the impression that this was a no-no & one should use
> > copyin/copout & friends to access memory on users's stacks. Although
> > this appears to work on the i386, if I try this on the alpha I take a
> > fatal trap when accessing *set.
> >
> > So -- how
On Mon, 6 Dec 1999, Parag Patel wrote:
[ ... ]
> In the proecss, we discovered a very interesting thing about the
> NCR/Symbios chips, at least the 810 and 825 series. Turns out that when
> they are executing their scripts, and the scripts access an on-board PCI
> register, that access actua
Go look at http://linux.3dfx.com/open_source
It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm
utterly freaked out.
Stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message <[EMAIL PROTECTED]> Darren Reed writes:
: Did all of that. When ejecting the card it says "freeing IRQ 10" (or
: words to that effect), which is the IRQ I used with it under Windows
: and NetBSD. How much can I specify on the "config" lines in pccard.conf ?
: Can I `wire down' irq's,
> > I was under the impression that this was a no-no & one should use
> > copyin/copout & friends to access memory on users's stacks. Although
> > this appears to work on the i386, if I try this on the alpha I take a
> > fatal trap when accessing *set.
> >
> > So -- how does this work on the i38
In some mail from Warner Losh, sie said:
>
> In message <[EMAIL PROTECTED]> Darren Reed writes:
> : How reliable should the ep0 driver be with 3c389d pcmcia cards ?
>
> I had no problems using 3.3 and my 3C589D, but I've only done minor
> stuff with that. I've done most of my work on -current,
In message <[EMAIL PROTECTED]> Mike Smith writes:
: Yup. Ignore the "problem in the application" part, as that predicates
: that the kernel and driver are working properly, which doesn't seem to be
: the case. The problem here is that the buffer between the top side of
: the driver and the app
In message <[EMAIL PROTECTED]> Darren Reed writes:
: ejecting a modem pcmcia card caused 3.3 to do the following:
: /kernel: sio2 unload,gone
: /kernel: Return IRQ=11
: /kernel: Card removed, slot 1
: /kernel: Card inserted, slot 0
: and then it was frozen.
:
: Will there be a 3.4 with things lik
In message <[EMAIL PROTECTED]> Darren Reed writes:
: How reliable should the ep0 driver be with 3c389d pcmcia cards ?
I had no problems using 3.3 and my 3C589D, but I've only done minor
stuff with that. I've done most of my work on -current, however. The
most likely problem is that you're using
On Mon, Dec 06, 1999 at 01:24:36PM -0800, Matthew Dillon wrote:
> :Well, I used to run -CURRENT in a commercial environment :-)
> :
> :And I got bashed here and elsewhere for doing it too.
> :
> :But, with the exception of some really egregious fuck-ups (on both my part
> :and those of people who
Regarding the PCI DMA problems and corruption, it reminds of me of a
similar PCI and DMA-related problem we had when porting OpenBSD to a
now-defunct NKK MIPS chipset. It may not be related, but here it is.
The port was up and running but under heavy load, say a compile, apps
(specifically one
I have one here..
(and all the specs)
the code changes needed to thte lnc driver are:
1/ new PCI ID :-)
2/ BSD equivalent of the following linux code:
case 0x2626:
chipname = "PCnet/Home 79C978";
fdx = 1;
/*
* This is based on specs published at www.amd.com
On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > I am doing some research on filesystem. I guess it may be faster to put
> > the disk inode with its file data together so that both can be read into
> > memory in one I/O.
>
> I still don't get it. To g
Has anyone gotten one of these to work with the lnc driver in current?
Looking at the chip specs, it is supposed to be software compatible with
the PCNet PCI parts, but it sports the "home networking" PHY that are
not supported on other LANCE parts.
If you've had success with these, please let me
In message <[EMAIL PROTECTED]>, "Ronal
d G. Minnich" writes:
>On Mon, 6 Dec 1999, Zhihui Zhang wrote:
>> I am doing some research on filesystem. I guess it may be faster to put
>> the disk inode with its file data together so that both can be read into
>> memory in one I/O.
>
>I still don't get
On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> I am doing some research on filesystem. I guess it may be faster to put
> the disk inode with its file data together so that both can be read into
> memory in one I/O.
I still don't get it. To get the file, you do a lookup. So the inode is in
memory. Th
> I was under the impression that this was a no-no & one should use
> copyin/copout & friends to access memory on users's stacks. Although
> this appears to work on the i386, if I try this on the alpha I take a
> fatal trap when accessing *set.
>
> So -- how does this work on the i386? Is the
On Mon, 6 Dec 1999, Matthew Dillon wrote:
> :On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> :
> :> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> :> > I have modified FFS filesystem code to put the disk inode at the beginning
> :> > of a file, i.e, the logical block #0 of each file begins with 128 b
On Mon, 6 Dec 1999, Julian Elischer wrote:
> how do you find the inode?
There is an inode address map to look up. Each entry is four bytes.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Mon, 6 Dec 1999, Matthew Dillon wrote:
> :On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> :
> :> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> :> > I have modified FFS filesystem code to put the disk inode at the beginning
> :> > of a file, i.e, the logical block #0 of each file begins with 128 by
how do you find the inode?
On Mon, 6 Dec 1999, Zhihui Zhang wrote:
>
> On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
>
> > On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > > I have modified FFS filesystem code to put the disk inode at the beginning
> > > of a file, i.e, the logical block #0 of eac
On 1999-Dec-07 07:23:49 +1100, David Wolfskill wrote:
>>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
>>From: Matthew Dillon <[EMAIL PROTECTED]>
>
>>The actual problem is sendmail's constant *rescanning* of the directory.
Which I forgot about :-(.
>To the extent that the directory is populated,
:> In otherwords, we should branch with the 4.1 release rather then the
:> 4.0 release.
:
:Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we
:branched one release afterwards and only after people threatened to
:mutiny if we didn't since the usual pattern up to that point had
I've been getting the osf1ulator (alpha/osf1 abi ported from NetBSD
over a year ago) on its feet again after this fall's signal changes.
When looking closely at the emulators which are currently in the tree,
I notice that they are they directly dereferencing memory which was
allocated on the use
:On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
:
:> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
:> > I have modified FFS filesystem code to put the disk inode at the beginning
:> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
:> > its disk inode and the rest of it are file
> I have some remarks about the issue. I donnot claim it is not a software
> problem, but ...
>
> 1) Given the actual differences between the ncr and sym drivers nowadays,
> I would be surprised if the problem was due to a driver software bug.
> A difference could be that recent drivers may use
: you wrote:
: : I wrote:
: :4) Using a different SCSI driver (Peter managed to get a driver from 4.0
: : hooked up under 3.3, and it survived two days of torture that would
: : have toasted things within an hour using the stock driver; you'll have
: : to ask him for details).
:
: Ed, t
:Well, I used to run -CURRENT in a commercial environment :-)
:
:And I got bashed here and elsewhere for doing it too.
:
:But, with the exception of some really egregious fuck-ups (on both my part
:and those of people who committed shit that didn't work AT ALL) it was, by
:far, the better option o
> In otherwords, we should branch with the 4.1 release rather then the
> 4.0 release.
Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we
branched one release afterwards and only after people threatened to
mutiny if we didn't since the usual pattern up to that point had been
:I tell you, it's just not possible to win, especially when those doing
:the most yelling are always conspicuously absent when crunch time
:comes. Matt wasn't really fully on board at the time and I'm not
:pointing my finger at him specifically, but it seems like everyone's
:hindsight is 20-20 wh
I have some remarks about the issue. I donnot claim it is not a software
problem, but ...
1) Given the actual differences between the ncr and sym drivers nowadays,
I would be surprised if the problem was due to a driver software bug.
A difference could be that recent drivers may use PCI optim
:On Mon, 6 Dec 1999, Zhihui Zhang wrote:
:> I have modified FFS filesystem code to put the disk inode at the beginning
:> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
:> its disk inode and the rest of it are file data.
:
:first question I have is, why?
:
:ron
Go
In message <[EMAIL PROTECTED]> Mike Smith writes:
: Growing the buffer isn't the solution; it should be big enough already.
: We need to work out why a system that should have no trouble with the
: data rate in question is croaking so trivially.
Growing the buffer is a solution. I only get a
:>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
:>From: Matthew Dillon <[EMAIL PROTECTED]>
:
:>The actual problem is sendmail's constant *rescanning* of the directory.
:
:To the extent that the directory is populated, yes. (Scanning an empty
:directory isn't an overwhelmingly resource-intensive
On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > I have modified FFS filesystem code to put the disk inode at the beginning
> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> > its disk inode and the rest of it are file data
On Mon, Dec 06, 1999 at 12:19:20PM -0800, Matthew Dillon wrote:
> :>:the problem, we can not address it. please provide this information
> :>:if it is available to you. if it is not, please provide us contact
> :>:information for the commercial entities experiencing the problem.
> :>:
> :>:jmb
>
> I've been with BSD a long time--from back when my email address was
> decvax!randvax!edhall. I want it to succeed, for reasons that are more
> emotional than rational; my nightmare was having to say that my project
> (1) worked on Solaris, (2) worked on Linux, but (3) broke FreeBSD.
And I hope
:I've confirmed that neither problem exists in 4.0. There are ample
:work-arounds, both hardware and software, including just not using 3.3.
:No fixes, though, just work-arounds... Workarounds for the NCR/FXP
:issue included:
:
:1) Using 2.2.8 (4.0 isn't a production option).
:2) Using a differe
> I think the solution here is to change the release mechanism slightly.
> I believe we made a huge mistake splitting of the 4.x tree from 3.x
> so early.
I was going to make a point about this, but thank you for making it
for me. :-)
My point was going to be that it was clearly not
> >
> > > Er, you should read the sio(4) manpage too. tty-level buffer overflows
> > > have nothing to do with interrupt latency/execution time.
> >
> > You mean this:
> >
> > sio%d: tty-level buffer overflow. Problem in the application. Input has
> > arrived faster than the give
NOTE: Please reply directly to my email address ([EMAIL PROTECTED])
Platform: x86, FreeBSD 3.3
While trying to link a threaded application with -pthread using the
following command line:
gcc -I/usr/local/include -L/usr/local/lib/mysql -pthread -o impd daemon.o
db.o handlers.o imp_list.o imp_ut
On Mon, 6 Dec 1999, Dennis wrote:
> Of course moving to -current to fix the problems in 3.x introduce a whole
> new set of problems, in which case you have an OS that is never going to be
> stable. When 4.0 is released we'll be told that the problems of 4.0 are
> fixed in -current. When does it e
As Matthew Jacob wrote ...
>
> > Another interesting cause for problems is duff powersupplies. As the
> > proverb goes "every machine is as good as it's PSU". E.g. I just struggeled
> > with a DLT tape unit that inexplicable reset itself. After examining the
> > 5Volts rail with a scope I found g
> :The main problem is that sendmail
> places all queue files (and there :are several for each
> undelivered message) in one directory
Sendmail 8.10 addresses this by allowing for multiple queue directories.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : It's documented in the sio(4) manpage, which is always worth reading.
>
> Even reading the sio manpage is unclear. All it says is that things
> are too slow. Steady state I don't get these, just every now and
> again it happens. No appare
On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> I have modified FFS filesystem code to put the disk inode at the beginning
> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> its disk inode and the rest of it are file data.
first question I have is, why?
ron
To Unsubscri
>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
>From: Matthew Dillon <[EMAIL PROTECTED]>
>The actual problem is sendmail's constant *rescanning* of the directory.
To the extent that the directory is populated, yes. (Scanning an empty
directory isn't an overwhelmingly resource-intensive operati
I've confirmed that neither problem exists in 4.0. There are ample
work-arounds, both hardware and software, including just not using 3.3.
No fixes, though, just work-arounds... Workarounds for the NCR/FXP
issue included:
1) Using 2.2.8 (4.0 isn't a production option).
2) Using a different NIC
:>:the problem, we can not address it. please provide this information
:>:if it is available to you. if it is not, please provide us contact
:>:information for the commercial entities experiencing the problem.
:>:
:>:jmb
:>
:>First, the statement was anecdotal -- all of the problems have been
At 11:05 AM 12/6/99 -0800, you wrote:
>
>:
>:
>:[snip]
>:> I am a good programmer and can fix things :-). But I've had to deal
with
>:> a number of nightmare situations by commercial entities deploying
FreeBSD
>:> and at least three (including one very recently) where commercial
entities
Mike-
> I should have summarised this by saying: Correct use of the latency
> timer will shorten your DMA bursts for you when necessary, giving you the
> best of both worlds. When it's safe to run a long burst, you will. When
> you need to push a device off the bus, that will happen too.
Af
In message <[EMAIL PROTECTED]>,
Nick Rogness <[EMAIL PROTECTED]> wrote:
>On Sun, 5 Dec 1999, Archie Cobbs wrote:
>
>> Brian Dean writes:
>> > No dropped packets, but definitely some occasional long delays before
>> > I get the echo. However, I must concede, based on other respondants,
>> > tha
I have modified FFS filesystem code to put the disk inode at the beginning
of a file, i.e, the logical block #0 of each file begins with 128 bytes of
its disk inode and the rest of it are file data.
Everything seems to be working. But I am stuck with an ELF executable
file stored in this layou
:>treatment, in roughly this order:
:>
:>3a) Complete check of all cables and the seating of connectors.
:>
:>3b) Examination of the drive(s) in question for any cooling or
:>mounting deficiencies. Depending on the SCSI errors in question,
:>I might even investigate
:Matthew Dillon wrote:
:> :
:> :All running software has serious problems, that's why it is never considered
:> :done. Taking the time to enumerate specific problems that are currently
:> :plaguing an installation is the only way anyone can possibly hope to help.
:> :Problems reports of "It don't
:You write:
:: we can not identify the specific problem from this message.
:: without sufficient information to indentify and hopefully reproduce
:: the problem, we can not address it. please provide this information
:: if it is available to you. if it is not, please provide us contact
:: i
:On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" <[EMAIL PROTECTED]> wrote:
:>Specifically, I'm planning a large mail server... which will use Sendmail...
:>and I'd really like to allocate the Sendmail queue files... which typically
:>have a rather short lifespan... on/in some sort of fi
:In message <[EMAIL PROTECTED]>,
:Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
:>Mail queue files are persistant enough (upwards of 5 days if a destination
:>is down) that you run a real risk of losing something important if
:>you crash and wipe. I would not use MFS at all and I wo
I haven't finished looking at the whole thing yet, but I see one
immediate (trivial to fix) problem:
+ BUF_LOCK(holdbp, LK_EXCLUSIVE))
I would recommend getting a *NON* blocking lock, and bumping your gap
mechanism if you can't get the lock (and not stor
:
:
:[snip]
:> I am a good programmer and can fix things :-). But I've had to deal with
:> a number of nightmare situations by commercial entities deploying FreeBSD
:> and at least three (including one very recently) where commercial entities
:> have refused to upgrade past 2.2.x due t
> I've just hacked a new ioctl into the ATAPI cdrom driver, which
> lets the user to specify (pronounce: ``slow down'' :) the speed
> of todays' extremely high speed drives.
ok, so i see you like the idea - so the question is: should we implement a
new ioctl for it, or - as like scsi - should we
In some mail from Matthew N. Dodd, sie said:
>
> On Mon, 6 Dec 1999, Darren Reed wrote:
> > How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets
> > detected by pccardd without any problems and a driver is attached to it,
> > but I'm not getting much in the way of performance
>Wes Peters wrote:
>> Wes Peters wrote:
>> >
>> > This might be the new 82559ER; I'm downloading the datasheet now. Have
>> > a peek at:
>> >
>> > http://developer.intel.com/design/network/datashts/index.htm
>>
>> Nope, that one is apparently device ID 0x1209. Too bad they don't have
Wes Peters wrote:
> Wes Peters wrote:
> >
> > This might be the new 82559ER; I'm downloading the datasheet now. Have
> > a peek at:
> >
> > http://developer.intel.com/design/network/datashts/index.htm
>
> Nope, that one is apparently device ID 0x1209. Too bad they don't have
> a PCI d
On Sun, 5 Dec 1999, Archie Cobbs wrote:
> Brian Dean writes:
> > No dropped packets, but definitely some occasional long delays before
> > I get the echo. However, I must concede, based on other respondants,
> > that something else must be going on and I cannot necessarily
> > attribute this to
> > On Sun, 05 Dec 1999, you wrote:
> Conversely, you can achieve the same latency reduction by setting the
> latency timer to 16, without increasing your overheads there. (This isn't
> actually entirely true, as you may run into busmaster ping-pong with more
> than one in the system, but you'll g
> On Sun, 05 Dec 1999, you wrote:
> >
> > > The question: Why doesn't this work... it seem so straight forward...
> >
> > I'm not sure about the code in question, but the basic assumptions you're
> > making about PCI's behaviour are flawed. To achieve the goal you're
> > trying to, you need to
83 matches
Mail list logo
