Dan Hollis <[EMAIL PROTECTED]> wrote:
>Did you ignore it or did you pay up?
>FWIW I recall there was prior art dating back to 1974 at the very least...
Here is editing version of some correspondence that answers your question.
> > > > US Patent #4,197,590 held by NuGraphics, Inc.
> >On Fri,
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> About a year later I was talking with a group of business owners who had
> also received a similar demand letter. Some paid, some didn't. Those
> who didn't pay were not pursued other than the occasional copy of the
> demand letter.
Probably they d
[EMAIL PROTECTED] writes:
> A. Datagram protocols do not work with mtus not allowing to send
>512 byte frames (even DNS).
This smells bad. Datagram protocol send sizes are only limited by
socket buffer size, nothing more. Fragmentation makes it work.
If you are really talking about side
2.4.1ac18 and loop-4 doesn't mix at all well, it didn't even compile (
understandably (sp?) if we think that a large hunk of loop.c is
rejected, and by studing the reject it seem to me that the original
version and loop-4 are going in differend directions :( ).
So, lacking the skil
< get your own 100 meg web site for only $11.95 per month today!
STOP PAYING $19.95 or more PER MONTH for your web site, WHEN YOU CAN GET A
100 meg web site FOR ONLY $11.95 PER MONTH NOW by simply calling 888 248
0765!
DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN T
>> >1) I know that some of the the MAC addresses given by tcpdump are
>> >invalid. Is this a bug? In what?
>>
>> Nope. The addresses (with mostly zeroes) are like IP addressses with many
>> zeroes or '255' - they handle concepts like "broadcast" or "me".
>
>Huh? It's a vanilla unicast IP datagram
[EMAIL PROTECTED] (Michael H. Warfield) writes:
> No... Close Source and proprietary protocols are then anthema to
>BOTH progress and innovation. When innovation is done in a close arena, it
These are two different things! Proprietary protocols are the death to
variety and customer choic
*** Please don't reply directly to me, either via CC: or To:.
*** I'll pick up any replies via linux-kernel. Thanks.
Henning P . Schmiedehausen writes:
> Maybe not. But you can use this print engine API to pay anyone to
> write a driver for you. What you just said, is exactly my point. You
> sai
:-> "kuznet" == kuznet <[EMAIL PROTECTED]> writes:
>> Over a radio link where
>> error rate causes exponential increases in probability of packet loss as
> Another myth. All they do error correction and have so high latency,
> that _increasing_ mtu only helps. And helps a lot
In irq_affinity_write_proc:
--- arch/i386/kernel/irq.c.old Sun Feb 18 12:22:06 2001
+++ arch/i386/kernel/irq.c Sun Feb 18 12:22:31 2001
@@ -1080,7 +1080,6 @@
err = parse_hex_value(buffer, count, &new_value);
-#if CONFIG_SMP
/*
* Do not allow disabling IRQs complet
[EMAIL PROTECTED] (Gregory Maxwell) writes:
>when you said commercial above) drivers for Linux, including the steaming
>pile of garbage your company ships.
"hostile behaviour of the open source community towards people that
don't agree to their ideas".
q.e.d. Thanks.
Regards
[EMAIL PROTECTED] (Torrey Hoffman) writes:
[...]
>Some things to consider, in no particular order:
[...]
Uniform support from most of the hard- and software vendors on this
planet. Support for 50.000+ different hardware expansions with all
their features from grabber cards to color printers and
[EMAIL PROTECTED] (Ben Ford) writes:
>> On the other hand, they make excellent mice. The mouse wheel and
>> the new optical mice are truly innovative and Microsoft should be
>> commended for them.
>>
>The wheel was a nifty idea, but I've seen workstations 15 years old with
>optical mice. It
[EMAIL PROTECTED] (Michael H. Warfield) writes:
> Excuse me? A 1 billion dolar investment in Linux is not
>supporting it?
On their own hardware.
> Setting up tier 1 and tier 2 support services for a half a dozen
>distributions is not supporting it?
For their own hardware.
> Porting their A
> Don't forget Microsoft's latest innovation: integrating copy
> protection for music into the upcoming Windows XP OS, preventing
> people from fully controlling their own computer hardware. Feh.
Thank people like IBM and the big movies companies like Sony for that.
-
To unsubscribe from this
[EMAIL PROTECTED] (Felix von Leitner) writes:
>Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
>> "If a company does not write a driver which works on all hardware
>> platforms in all cases and gives us the source, then it is better,
>> that the company writes no drivers at all."
>>
On Sun, 18 Feb 2001, Henning P. Schmiedehausen wrote:
>
> Uniform support from most of the hard- and software vendors on this
> planet. Support for 50.000+ different hardware expansions with all
> their features from grabber cards to color printers and network cards
> to 3D graphics accelerators
Hello,
as fas as I can see from fdatasync man page, and from the latest kernel
sources (2.4.1ac3, fs/buffer.c), they are equivalent.
Using of fdatasync in database can gain significant gain on systems which
supports it (on HP it gains up to 25% with pg_bench on PostgreSQL 7.1b5).
Are there an
I wrote:
>The matter with me is: "Vendors AAA ships its hardware product with a
>driver for i386/Linux". The driver may be closed source, but at least
>there _is_ a driver. Russell now says: "This is bad, because I can't use
>the driver for my ARM box. So the vendor should ship no driver at
>all.
On Sunday 18 February 2001 18:22, Denis Perchine wrote:
> Hello,
>
> as fas as I can see from fdatasync man page, and from the latest kernel
> sources (2.4.1ac3, fs/buffer.c), they are equivalent.
>
> Using of fdatasync in database can gain significant gain on systems which
> supports it (on HP it
sym53c875-0:0: ERROR (0:18) (1-21-4d) (f/3d) @ (script 820:1100).
sym53c875-0: script cmd = 1100
sym53c875-0: regdump: da 10 c0 3d 47 0f 00 07 46 01 80 21 80 01 01 00 00 80 d1 0f 08
ff ff ff.
sym53c875-0: restart (scsi reset).
sym53c875-0: Downloading SCSI SCRIPTS.
sym53c875-0-<0,0>: wid
On Sun, 18 Feb 2001, Mordechai Ovits wrote:
> Looks like you were bitten by either the RAID 1 bugs or the elevator
> bugs. Try a 2.4.2-pre4 or an 2.4.1-ac18 kernel. Should solve it.
the crash does not look like to be even in the neighborhood of RAID1 or
elevator (it crashed in __page_alloc() m
My system has a IDE ATAPI CD-RW (Matshita CW 7586) and has a serious
problem reading the last audio track of an audio CD. Reading the rest of
the tracks is Ok, but when trying to rip the last one I get the following
error:
[With cdda2wav, versions 1.9 and 1.10a13]
CDB: 47 00 00 3D 0D 3C 3D 0D
On Tue, 13 Feb 2001, Rik van Riel wrote:
> On Tue, 13 Feb 2001, Mike Galbraith wrote:
> > On Mon, 12 Feb 2001, Marcelo Tosatti wrote:
> >
> > > Could you please try the attached patch on top of latest Rik's patch?
> >
> > Sure thing.. (few minutes later) no change.
>
> That's because your probl
> Looks like you were bitten by either the RAID 1 bugs or the elevator bugs.
> Try a 2.4.2-pre4 or an 2.4.1-ac18 kernel. Should solve it.
Just installed 2.4.2pre4, seems to be stable for now (testing it ATM,
running dnetc, several kernel compiles etc.). On 2.4.1 even su segfault'd if
the server
Henning P. Schmiedehausen writes:
> The matter with me is: "Vendors AAA ships its hardware product with a
> driver for i386/Linux". The driver may be closed source, but at least
> there _is_ a driver. Russell now says: "This is bad, because I can't use
> the driver for my ARM box. So the vendor sh
Hello
Unless I misunderstand s_maxbytes it says how large a file can be on the
fs. I assume it is enough for a fs to set that and then it knows the vfs
will not ask it to go beyond that limit?
Is it ok to at mount time set it to non-LFS and then later change it to be
something larger? smbfs doe
I have two ext2 CD-ROMs. One of them I can mount the normal way, the other I
can't. Both are ok according to debugfs and e2fsck and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom' instead, both works.
The one that doesn't work have a blocksize of 1024 according to debugfs:
Block size = 1024,
Keith Owens <[EMAIL PROTECTED]> writes:
>
> Would people prefer the C/ASM filename in BUG() messages instead of the
> include header? If so I will add it to my todo list for the makefile
> rewrite. Of course you can still use __FILE__ and __LINE_ if you
> really want to report the error against
On Wed, 14 Feb 2001, Grant Grundler wrote:
> Philipp Rumpf wrote:
> > Jeff Garzik wrote:
> > > Looks ok, but I wonder if we should include this list in the docs.
> > > These is stuff defined by the PCI spec, and this list could potentially
> > > get longer... (opinions either way wanted...)
>
>
Hi.
Thought I'd toss my 0.02sek into the discussion.
> > > objective, arent we?
> >Nope. Are you claiming to be?
> >
> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> >... Rant delete
"Henning P. Schmiedehausen" wrote:
>
> [EMAIL PROTECTED] (Michael H. Warfield) writes:
>
> > Excuse me? A 1 billion dolar investment in Linux is not
> >supporting it?
>
> On their own hardware.
Which is really the point and they won't be the only ones. If IBM wants
to attract and keep custome
Hi.. well this is off-topic sorry.. somebody is going to kill me
but.. somebody has to make sure about this,
Being aware about the new Microsoft "world domination" attempt with its
.NET platform and after years watching how the Internet is getting more
and more commercial (well this maybe is not
On Sunday, February 18, 2001 02:10:50 AM +0100 Frank de Lange
<[EMAIL PROTECTED]> wrote:
>> At least the patch didn't make it worse. Would anyone care to comment on
>> how the elf-dynstr-gc option changes the file access patterns for the
>> compile?
>
> It does not change the file access pa
On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote:
> >
> > On the other hand, they make excellent mice. The mouse wheel and
> > the new optical mice are truly innovative and Microsoft should be
> > commended for them.
> >
> The wheel was a nifty idea, but I've seen workstations 15 years
On Sunday, February 18, 2001 03:07:27 AM +0100 Frank de Lange
<[EMAIL PROTECTED]> wrote:
>
> And no, I'm not running RedHat 7.x for those who might think so (and
> automatically blame everything on it).
>
Minor nit, but I'd rather clear it up now. Which distribution you run
doesn't matter for
>Have you any idea the breadth of cards and chips that aic7xxx supports?
>Sure, Justin's driver does great with your shiny new 7899, but can you
>verify that it also drives the 8-year-old EISA AHA-2740 I still have
>sitting around (actually retired to the parts pile, but that's beside
>the point,
Hello!
> Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
None of the options apply to sendfile(). It is not socket level
operation. You have to use alarm for it.
BTW, if you have enough fast network, you probably can observe
that sendfile() is even not interrupted by signals. 8)
> Minor nit, but I'd rather clear it up now. Which distribution you run
> doesn't matter for debugging. What does matter is that we've got known
> problems with a given compiler, and that compiler goes by a few different
> flavors with the same version number. Since there are known problems, if
>
On Sun, 18 Feb 2001, Henning P. Schmiedehausen wrote:
> >- Innovative new hardware devices are more likely to be based on
> >Linux than any Microsoft OS. For example, the TiVO, the coolest
> >improvement to television since the VCR.
Henning,
When you begin to learn that OpenSource is the way a
From: Jon Forsberg <[EMAIL PROTECTED]>
I have two ext2 CD-ROMs. One of them I can mount the normal way,
the other I can't. Both are ok according to debugfs and e2fsck
and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom'
instead, both work.
The one that doesn't wo
On Sun, 18 Feb 2001, Michael H. Warfield wrote:
> On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote:
> > >
> > > On the other hand, they make excellent mice. The mouse wheel and
> > > the new optical mice are truly innovative and Microsoft should be
> > > commended for them.
> > >
> > The
On Sun, Feb 18, 2001 at 09:50:17AM -0800, Andre Hedrick wrote:
[...]
> If you do not like that rule, LEAVE!
[...]
> if I catch you abusing the privildge of use of my work, I will
> pursue you in terms defined as actionable.
[...]
> And you do not have the knowledge or authority to comment on th
Here is a bug report in the format requested by linux/REPORTING-BUGS:
[1] page_alloc 2.4.1 kernel BUG running java 1.3.0
[2] Running java 1.3.0 e.g. 'java -jar SwingSet2.jar' etc. causes system
crashes and on other occasions, problems running other programs (e.g.
umount) subsequently. This does
On Sun, 18 Feb 2001, Gregory S. Youngblood wrote:
> I remember being at a computer show in Minneapolis where a small company
> was showing off this mouse that worked on a variety of surfaces without a
> ball. I'm trying to remember if the mouse was optical or used yet another
> method of function
On Fri, Feb 16, 2001 at 05:40:04PM -0800, Jack Bowling wrote:
> I am trying to use the --mac-source option in the netfilter code to better
> refine access to my linux box. However, I have run up against something. The
> router through which my private subnet work box passes sends a 14-group
> "inv
Hello!
> Yes. The 5.6.7.8 machine is connected to the Internet via a Linksys
> "router" that is also performing masquerade.
>
> I will be very angry if this turns out to be the culprit.
I am afraid it is. It corrupts packets preserving their checksum.
Look:
> Trace taken from 1.2.3.4 machi
Rob Leathley wrote:
>
> [X] I have been suffering a lot of memory paging related Oops' on the
> above PC since upgrading to the 2.2.16 kernel. Most of these problems
> are fixed in 2.4.1 appart from the above. These problems don't appear
> on a faster machine (e.g. P3 733MHz) so could be relate
On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote:
> On Sun, 18 Feb 2001, Michael H. Warfield wrote:
> > On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote:
> > > >
> > > > On the other hand, they make excellent mice. The mouse wheel and
> > > > the new optical mice are
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> Someone has added
> /*
> * These are good guesses for the time being.
> */
> for (i = 0; i < sr_template.dev_max; i++) {
> sr_blocksizes[i] = 2048;
> sr_hardsizes[i] = 2048;
>
On Sat, Feb 17 2001, John Fremlin wrote:
> Specifically, this part:
>
> @@ -2324,11 +2309,17 @@
> sense.ascq == 0x04)
> return CDS_DISC_OK;
>
> +
> + /*
> +* If not using Mt Fuji extended media tray reports,
> +
Hi,
On a 4GB SMP box, configured with HIGHMEM support, making a 670G
(obviously using a volume manager) ext2 file system takes 12minutes (over
10minutes of sys time).
One problem is buffer allocations do not use HIGHMEM, but the
nr_free_buffer_pages() doesn't take this into account causing
b
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
>
> None of the options apply to sendfile(). It is not socket level
> operation. You have to use alarm for it.
Hi Alexey,
Actually sendfile() _does_ timeout using SO_SNDTI
Hello!
> So the actual timeout would be 2 * SO_SNDTIMEO.
It will timeout if write of some page blocks for SO_SNDTIMEO.
If transmission of any page never takes more than SO_SNDTIMEO it never
times out.
You can think about sendfile() as subroutine doing:
for (;;) {
read(4
> A value of hardsect_size[] means: this is the smallest size
> the hardware can work with. It is therefore a serious mistake
> just to come with "a good guess". This value is used only
You are defeating the entire purpose of having a hardware sector
size independently from t
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > So the actual timeout would be 2 * SO_SNDTIMEO.
>
> It will timeout if write of some page blocks for SO_SNDTIMEO.
.. unless that page was partially written, in which case a short write
count is returned (rather than a timeout error), a
Hello!
> .. unless that page was partially written, in which case a short write
> count is returned (rather than a timeout error), and the loop goes around
> again.
sendfile() does not return on partial write and tries to push more
until error. On fast link it most likely succeeds, so that it is
Hello!
> Message size != MTU.
Alan, you misunderstand _sense_ of the problem.
Fragmentation does _not_ work on poor internet more. At all.
Look at original report. It failed _only_ because his intemediate
node failed to forward fragmented packets.
Alexey
-
To unsubscribe from this list: send t
| Since that time, about 1986, I learned that there is a whole cottage
| industry of going through old, but not too old, patents and seeing how
| they can be misconstrued to apply to current technology, buying the
| patent for cheap, and then threatening "infringers". More or less
| an extortion
Hello!
> Wouldn't it be simpler to just fix the bugs
There are no bugs.
There is phylosophical discussion about current state of internet
communications.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
| Since that time, about 1986, I learned that there is a whole cottage
| industry of going through old, but not too old, patents and seeing how
| they can be misconstrued to apply to current technology, buying the
| patent for cheap, and then threatening "infringers". More or less
| an extortion
Hi Neil, all,
The nfs daemons run holding the global kernel lock. They still hold
this lock over calls to file_op's read and write.
The file system kernel interface (FSKI) doesn't require the kernel lock
to be held over these read/write calls. The nfs daemons do not require
that the reads
Hello!
> This smells bad. Datagram protocol send sizes are only limited by
> socket buffer size, nothing more. Fragmentation makes it work.
The thread was started from the observation that fragmented frames
do _not_ pass through router. See? 8)
Path mtu discovery exists exactly to help to sol
I've been poring over the x86 boot code for a while now and I've been
considering writing a FAQ on the boot process (mostly for my own use,
but maybe others will be interested). This would include all relevant
information on setting up the x86 hardware for a boot (timers, PIC, A20,
protected mode,
Hi,
I am sorry the might be of the list's normal content.
My colleague will be on leave in may this year in states and wish to attend any I.T
related conference during that period.
Can you please send any info. if you are aware of any for that period.
Thanks,
Jones
Find the best deals on t
From: Jens Axboe <[EMAIL PROTECTED]>
On Sat, Feb 17 2001, John Fremlin wrote:
> Specifically, this part:
>
> @@ -2324,11 +2309,17 @@
> sense.ascq == 0x04)
> return CDS_DISC_OK;
>
> +
> + /*
>
Scott Long wrote:
> Does there exist an outline (detailed or not) of the boot process from
> the point of BIOS bootsector load to when the kernel proper begins
> execution? If not would anyone be willing to help me understand
> bootsect.S and setup.S enough so that I might write such an outline?
Hello!
> Please cite an exact RFC reference.
Imagine, I found this reference yet. This is rfc1191, of course. 8)
in the MSS option. The MSS option should be 40 octets less than the
size of the largest datagram the host is able to reassemble (MMS_R,
as defined in [1]); in many cases, t
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> > A value of hardsect_size[] means: this is the smallest size
> > the hardware can work with. It is therefore a serious mistake
> > just to come with "a good guess". This value is used only
>
> You are defeating the entire purpose of
> There is one bug that might affect the Alpha in there. Once you have
> patched your kernel, you should change the typedef of bus_addr_t in
> drivers/scsi/aic7xxx/aic7xxx_osm.h from uint32_t to dma_addr_t:
>
> typedef uint32_t bus_addr_t
>
> becomes
>
> typedef dma_addr_t bus_addr_t
>
> I ju
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> > + /*
> > +* If not using Mt Fuji extended media tray reports,
> > +* just return TRAY_OPEN since ATAPI doesn't provide
> > +* any other way to detect this...
> > +
Hello , i have some problems with my inspiron 8000
running kernler 2.4.1-ac16 and hope someone on this
list can help me.
the built in network card do not function after a
suspend/resume , the only messages i receive is
"eepro100: wait_for_cmd_done timeout!" , i belive
the problem is in the pc
> You are defeating the entire purpose of having a hardware sector
> size independently from the software block size. And 2kB is a
> valid guess, apart from the drives that do 512 byte transfers too
> 2kB is really the smallest transfer we can do.
>
> : And
Have you seen Janet_Reno?
ftp://linux01.gwdg.de/pub/cLIeNUX/interim/Janet_Reno.tgz IIRC.
Janet is an x86 bootsector that gets into protected mode and can
use the AT BIOS in pmode interrupts. It's written with a bunch of
m4 macros I call asmacs that I'm currently basing an assembler in
Bash on.
In message <96o9uf$j4h$[EMAIL PROTECTED]>, "Henning P.
Schmiedehausen" write
s:
> [EMAIL PROTECTED] (Gregory Maxwell) writes:
>
> >when you said commercial above) drivers for Linux, including the steaming
> >pile of garbage your company ships.
>
> "hostile behaviour of the open source community
On Sun, 18 Feb 2001, Scott Long wrote:
> Does there exist an outline (detailed or not) of the boot process from
> the point of BIOS bootsector load to when the kernel proper begins
> execution? If not would anyone be willing to help me understand
> bootsect.S and setup.S enough so that I might wr
>Here's the dmesg when it happened (I took this via serial console which I was
>logged in to)
>[root@kakarot:/lvm/misc] cp /dev/zero .
>(scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x33.
Someone is sending a request that your drive believes specifies a data
transfer to the dri
> On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> > About a year later I was talking with a group of business owners who had
> > also received a similar demand letter. Some paid, some didn't. Those
> > who didn't pay were not pursued other than the occasional copy of the
> > demand letter.
On S
On Sun, 18 Feb 2001, Henning P . Schmiedehausen wrote:
> Bla, bla, bla. The usual Andre Hedrick rant about how superior you're
> to all other, threats and the cited hostility of "open source advocats"
> about everyone not their opinion.
>
> You may be a really talented software developer with a
In init/main.c, do_basic_setup() we have:
start_context_thread();
do_initcalls();
start_context_thread() calls kernel_thread() to start the keventd
thread. Then do_initcalls() calls all the init functions and
finishes by calling flush_scheduled_tasks(). This function ends
up c
Andre Hedrick writes:
> Those are not threats they are terms to enforce the License you agreed
> upon the very act of editing the source code that you are using in the
> kernel.
Get it right, Andre. The mere act of editing a file that is part of a
GPL-licensed source distribution doesn't bind
On Sun, 18 Feb 2001, Steve VanDevender wrote:
> Andre Hedrick writes:
> > Those are not threats they are terms to enforce the License you agreed
> > upon the very act of editing the source code that you are using in the
> > kernel.
>
> Get it right, Andre. The mere act of editing a file that
Hi all,
This is an typical mail from an experienced user-land programmer who wants to
help in kernel development ;D.
I've been lurking for a while in this list and I'm wondering if this is the
right list for asking stupid newbie questions. Is it?. If not, do you know
one?. Where I can find
Kenn Humborg writes:
> When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> make sure that the threads have run before continuing. Shouldn't
> start_context_thread() do something similar?
I think this would be a good idea. Here is a patch to try. Please report
back if it wo
On Sun, 18 Feb 2001, Pedro Diaz Jimenez wrote:
> This is an typical mail from an experienced user-land programmer who wants to
> help in kernel development ;D.
>
> I've been lurking for a while in this list and I'm wondering if this is the
> right list for asking stupid newbie questions. Is it
I have a Compaq Proliant 1600 server which can be hung on demand with all
the 2.4 series kernels I have tried (2.4, 2.4.1 & 2.4.2-pre3). Kernel 2.2.16
runs perfectly (from a default RH7.0).
I have ensured that the server meets the necessary requirements for the 2.4
kernels (modutils etc) and I
Thanks to all,
I've just found http://www.linuxnewbie.org to be a good start point
Pedro
On Sunday 18 February 2001 23:57, Jeff Garzik wrote:
> On Sun, 18 Feb 2001, Pedro Diaz Jimenez wrote:
> > This is an typical mail from an experienced user-land programmer who
> > wants to help in kernel dev
>> > On the other hand, they make excellent mice. The mouse wheel and
>> > the new optical mice are truly innovative and Microsoft should be
>> > commended for them.
>> >
>> The wheel was a nifty idea, but I've seen workstations 15 years old with
>> optical mice. It wasn't MS's idea.
>
> I
On Sun, Feb 18, 2001, lafanga lafanga <[EMAIL PROTECTED]> wrote:
> The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately
> after they exit (with exit status 0). I cannot pinpoint why the kernel hangs
> and would appreciate any help. The only thing I suspect it may be is that i
There is indeed a PS/2 mouse and it is plugged in. As far as I know its an
Intel 440BX chipset since its a 100Mhz bus.
>From: Johannes Erdfelt <[EMAIL PROTECTED]>
>To: lafanga lafanga <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: Proliant hangs with 2.4 but works with 2.2.
>Date: Sun
Hi,
I migrated some exported disks over to reiserfs and had no luck when I
mounted the disk via NFS on another machine. I've noticed many messages
about reiser and NFS in the archives, but my understanding was that
it had been cleared up. In particular, the Configure.help in 2.4.2-pre4
says "r
I'm calling this "BETA 1" because I currently feel that all
performance and other issues have been addressed and that the
patch is up for serious consideration for inclusion into a
future 2.4.x release:
ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2p4-1.diff.gz
Besides mergin
On Sunday February 18, [EMAIL PROTECTED] wrote:
>
> Hi,
>
> I migrated some exported disks over to reiserfs and had no luck when I
> mounted the disk via NFS on another machine. I've noticed many messages
> about reiser and NFS in the archives, but my understanding was that
> it had been cleare
On Sun, 18 Feb 2001 23:09:17, "lafanga lafanga" <[EMAIL PROTECTED]>
wrote:
> I have a Compaq Proliant 1600 server which can be hung on demand with all
> the 2.4 series kernels I have tried (2.4, 2.4.1 & 2.4.2-pre3). Kernel 2.2.16
> runs perfectly (from a default RH7.0).
>
> I have ensured that
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
>
> None of the options apply to sendfile(). It is not socket level
> operation. You have to use alarm for it.
>
> BTW, if you have enough fast network, you probably can obs
> Is it ok to at mount time set it to non-LFS and then later change it to be
> something larger? smbfs doesn't actually know what the server and smbmount
> negotiates until later, but no smbfs operation can take place before that
> anyway.
You can change it per superblock later at the moment. Its
On Sun, 18 Feb 2001, Michael H. Warfield wrote:
> On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote:
>
> > I remember being at a computer show in Minneapolis where a small company
> > was showing off this mouse that worked on a variety of surfaces without a
> > ball. I'm tryin
> So put 0 and sure anyone can submit I/O on the size that they want.
> Now the driver has to support padding reads, or gathering data to do
> a complete block write. This is silly. Sr should support 512b transfers
> just fine, but only because I added the necessary _hacks_ to support
> it. sd doe
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> > Strange. The twelve or so CD readers I have here are all
> > able to read 512-byte sectors. I am quite willing to believe
>
> I think most Plextor and Yamaha do, but it's not guaranteed to
> be supported. And it definitely won't fo
On Mon, 19 Feb 2001, Chris Evans wrote:
> > BTW, if you have enough fast network, you probably can observe
> > that sendfile() is even not interrupted by signals. 8) But this
> > is possible to fix at least. BTW the same fix will repair SO_*TIMEO
> > partially, i.e. it will timeout after n*timeo
1 - 100 of 122 matches
Mail list logo
