Hello,
Same here as reported.
restoring lvm.c from 2.4.3 into 2.4.4-pre? "fixes" this. (tested not ac's
kernel)
Greatings,
On Mon, 16 Apr 2001, Rik van Riel wrote:
> Hi,
>
> 2.4.3-ac4 seems to work great on my test box (UP K6-2 with SCSI
> disk), but 2.4.3-ac6 and 2.4.3-ac7 hang pretty hard wh
[EMAIL PROTECTED] wrote:
> In the long run, it probably makes sense to adjust the algorithms to
> allow for non-power-of-two inode sizes,
If you don't mind, does that imply packing inodes across block
boundaries?
Regards,
Jeff
--
Jeff Garzik | "The universe is like a safe to wh
Alan Cox <[EMAIL PROTECTED]> writes:
> > I don't want nor need file permissions. A program would look like this:
>
> Your example opens/mmaps so has file permissions. Which is what I was asking
There are no permissions on the mutex object. It is the shared memory
which counts. If you would i
On Thu, Apr 19, 2001 at 12:26:03PM -0700, Ulrich Drepper wrote:
> In any case all kinds of user-level operations are possible as well
> and all the schemes suggested for dealing with the common case without
> syscalls can be applied here as well.
Are you sure, you can implement SMP-safe, atomic o
I sent this report to the people indicated below, whose names I got from the
MAINTAINERS file in the 2.4.3 distribution, but the email address for Mr.
MacKerras is no longer good and Mr. Chastain wrote me back that he is not
following 2.4 issues.
I have not yet heard from Mr. Owens.
Any suggesti
úÄÒÁ×ÓÔ×ÕÊÔÅ. âïìøûå, ÞÅÍ ÐÒÏÓÔÏ âåóðìáôîùê èïóôéîç
1. ó÷ïê íáçáúéî. ó÷ïñ óôòáîéþëá.
÷Ù ÈÏÔÉÔÅ áâóïìàôîï âåóðìáôîï ÉÍÅÔØ ÓÏÂÓÔ×ÅÎÎÙÊ, ÐÏÌÎÏÃÅÎÎÙÊ éîôåòîåô- íáçáúéî Ó
ÓÏÂÓÔ×ÅÎÎÙÍ ÕÎÉËÁÌØÎÙÍ ÁÄÒÅÓÏÍ: ÉÍÑ.internetmagazin.ru? âÅÚ ÁÒÅÎÄÙ, ÐÏ ×ÙÂÒÁÎÎÏÍÕ
÷ÁÍÉ
ÛÁÂÌÏÎÕ. ÷ ÔÅÞÅÎÉÉ 10 ÍÉÎ
On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote:
>
> We have found that one of our programs can cause system-wide
> corruption of the x86 FPU under 2.2.16 and 2.2.17.
>
> We see this problem on dual 550MHz Xeons with 1GB RAM.
Hm, I started to wonder if this is not somewhat rel
> I don't want nor need file permissions. A program would look like this:
Your example opens/mmaps so has file permissions. Which is what I was asking
> The shared mem segment can be retrieved in whatever way. The mutex in
> this case is anonymous. Everybody who has access to the shared mem
>
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
You may well need to 'make clean' before building -ac8 as the GDT layout
has changed a little.
2.4.3-ac10
o Merge Linus 2.4
On Thu, Apr 19, 2001 at 07:55:20AM -0400, Alexander Viro wrote:
> Erm... Folks, can ->s_inode_size be not a power of 2? Both
> libext2fs and kernel break in that case.
This was a project that was never completed. I thought at one point
of allowing the inode size to be not a power of 2, bu
AJ Lewis wrote:
> Ok, the issue here is that we're trying to get a release out and so anything
> that majorly changes the code is getting shunted aside for the moment. It
> would be stupid to just add everything that comes in on the ML without
> review. Linus does the exact same thing. I've sai
Alan Cox <[EMAIL PROTECTED]> writes:
> mknod foo p. Or use sockets (although AF_UNIX sockets are higher latency)
> Thats why I suggested using flock - its name based. Whether you mkstemp()
> stuff and pass it around isnt something I care about
>
> Files give you permissions for free too
I don't
Eric,
Please apply this patch before doing anything in the ARM tree.
What you will find is that most of your symbols in these files were due
to it being out of date. However, I'd say the bigger problem is the
symbols that don't exist.
Also, you may not have the full story of the Config.in file
On Thu, Apr 19, 2001 at 09:56:52PM +0200, [EMAIL PROTECTED] wrote:
> Your mail to 'linux-lvm' with the subject
>
> Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list
>
> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
>
> As far as getting patches into the stock kernel, we've been sending patches
> to Linus for over a month now, and none of them have made it in. Maybe
> someone has some pointers on how we get our code past his filters.
Has it occured to you that some of this might be because the code does stuff
On Thu, Apr 19, 2001 at 01:45:20PM -0600, Andreas Dilger wrote:
> I don't think that the subscription is necessarily the only issue. I'm
> subscribed to all of the LVM mailing lists, and still a lot of what I
> submit (legitimate bug fixes, and not just features/code cleanup) does
> not get added
On Thu, Apr 19 2001, AJ Lewis wrote:
> As far as getting patches into the stock kernel, we've been sending patches
> to Linus for over a month now, and none of them have made it in. Maybe
> someone has some pointers on how we get our code past his filters.
The diff between 2.4.4-pre LVM and your
On Thu, 19 Apr 2001, Andreas Dilger wrote:
> I don't think that the subscription is necessarily the only
> issue. I'm subscribed to all of the LVM mailing lists, and
> still a lot of what I submit (legitimate bug fixes, and not just
> features/code cleanup) does not get added to CVS. Yes, the
>
On Thu, Apr 19, 2001 at 01:45:20PM -0600, Andreas Dilger wrote:
> I don't think that the subscription is necessarily the only issue. I'm
> subscribed to all of the LVM mailing lists, and still a lot of what I
> submit (legitimate bug fixes, and not just features/code cleanup) does
> not get added
> Not to be negative, but isn't Alan the pot calling the kettle black? You
> use ORBS to block email as well, with no hope of reprieve. AFAIK, the
I dont stop other people discussing the kernel. Its very very different.
> linux-lvm list has a moderator which _should_ forward legitimate emails
Alan Cox <[EMAIL PROTECTED]> writes:
> > can libraries use fast semaphores behind the back of the user? They might
> > well want to use the semaphores exactly for things like memory allocator
> > locking etc. But libc certainly cant use fd's behind peoples backs.
>
> libc is entitled to, and mos
> All it would have taken was a request and a good reason for doing so, but
> I guess this is one way to do it. Just don't complain about spam. :)
I think you'll find several folks who run linux-kernel and other lists like
the linux.nl mailhub more than happy to help there
Alan
-
To unsubscri
> "Jens" == Jens Axboe <[EMAIL PROTECTED]> writes:
Jens> First one gets a mail saying that the mail sent is queued for
Jens> moderator approval, since I'm not on the list. Then later a
Jens> second mail arrives, saying the mail has been rejected by the
Jens> moderator.
Yep. Same here. Late
AJ Lewis writes:
> On Thu, Apr 19, 2001 at 08:02:50PM +0100, Alan Cox wrote:
> > Well their approach to patches that fix bugs is to reject emails. They've
> > done that to stuff I've reported any many others. So there is a problem.
> > And it's kind of hard to discuss a problem when you are being
The list is now open. I've talked to our admin and he's opening it up.
Send me e-mail if it doesn't work, 'cause something else is broken.
All it would have taken was a request and a good reason for doing so, but
I guess this is one way to do it. Just don't complain about spam. :)
Regards,
AJ
> "AJ" == AJ Lewis <[EMAIL PROTECTED]> writes:
AJ> On Thu, Apr 19, 2001 at 09:17:29PM +0200, Jes Sorensen wrote:
>> This was tried, trust me. We didn't create this list because
>> someone forgot to respond to a single posting. As we wrote in the
>> announcement there has been too many inciden
On Thu, Apr 19, 2001 at 09:35:51PM +0200, Jes Sorensen wrote:
> > ">" == AJ Lewis <[EMAIL PROTECTED]> writes:
> >> Hmm...i guess there is a communication issue here. It sounds like
> >> the message that our ML server was sending was misleading. We were
> >> not rejecting mail because of cont
> ">" == AJ Lewis <[EMAIL PROTECTED]> writes:
>> Hmm...i guess there is a communication issue here. It sounds like
>> the message that our ML server was sending was misleading. We were
>> not rejecting mail because of content. The ML server was rejecting
>> it because the address was not s
Eric S. Raymond writes:
> > The ones that show up in arch/arm/def-configs are purely because I've been
> > keeping back the updates to these files; each time the config structure
> > changes, I get a nice big patch from people with the new def-configs. I
> > didn't want to inflict this too regula
> I fail to see how this works across processes. How can you generate a
> file descriptor for this pipe in a second process which simply shares
> some memory with the first one? The first process is passive: no file
> descriptor passing must be necessary.
mknod foo p. Or use sockets (although A
On Thu, Apr 19 2001, AJ Lewis wrote:
> Did anyone bother to e-mail the list admins? Perhaps it was too difficult
> to figure out who to mail about this, but I know for a fact that Rik van
> Riel and Jens Axboe could post to [EMAIL PROTECTED] It would have been
> nice if they had mentioned someth
> The problem is that at the low point in the cycle, the machine is
> unusable. It is utterly unresponsive until the writes complete, which can
> take a very long time (in the case of the ppc machine, several minutes!)
> Anything that does disk I/O will block for a long time - having 'ls' take
>
Patrick Mochel <[EMAIL PROTECTED]> writes:
[...]
> > > I can see at least two types of events - (forgive the lack of colorful
> > > terminology) passive and active. Passive events are simply providing
> > > status updates, much like the events described above. These are simply so
> > > some UI c
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Looks good to me. Anybody want to try this out and test some benchmarks?
I fail to see how this works across processes. How can you generate a
file descriptor for this pipe in a second process which simply shares
some memory with the first one? The
On Thu, Apr 19, 2001 at 09:17:29PM +0200, Jes Sorensen wrote:
> This was tried, trust me. We didn't create this list because someone
> forgot to respond to a single posting. As we wrote in the announcement
> there has been too many incidents: At least two people got kicked off
> the old lvm list f
Al writes:
> > I had always assumed that it would be a power-of-two size, but since it
> > is an undocumented option to mke2fs, I suppose it was never really
> > intended to be used. It appears, however, that the mke2fs code
> > doesn't do ANY checking on the parameter, so you could concievably m
On Thu, Apr 19, 2001 at 08:02:50PM +0100, Alan Cox wrote:
> Well their approach to patches that fix bugs is to reject emails. They've done
> that to stuff I've reported any many others. So there is a problem. And its
> kind of hard to discuss a problem when you are being moderated out of existance
> "AJ" == AJ Lewis <[EMAIL PROTECTED]> writes:
AJ> It is unfortunate that this could not have been resolved in a more
AJ> mature manner.
Personally, I find it exceedingly immature that my postings get
moderated to the bitbucket every time I report a bug in your code.
This is simply not th
> ">" == AJ Lewis <[EMAIL PROTECTED]> writes:
>> It is unfortunate that this could not have been resolved in a more
>> mature manner. Saying "I don't like the way somebody is doing
>> something. I won't bother to talk to them about it, I'll just
>> flame them and try to undermine their work
> > > > (1) Battery status, power status, UPS status polling. It
> > > > should be possible for lots of processes to do this
> > > > simultaneously. [That does not prohibit a single process
> > > > querying the kernel and all the others querying it.]
> > >
> > > S
Patrick Mochel <[EMAIL PROTECTED]> writes:
[...]
> > Solution. Have a special procfs or dev node that any number of people
> > can select(2) or read(2). Protocol text. Syntax:
> >
> >
> >
> > Where is one of the strings
> > OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, is a space char
On 2001.04.19 21:04:26 +0200 Alan Cox wrote:
> > Is blackbox broken? Or is this a kernel bug? Or a bug in the nvidia
> > drivers?
> > I hope you can fix it (if it is a kernel bug)...
>
> Only Nvidia can help you. Reproduce the problem from a boot where the
> nvidia
> drivers have never been load
> Still have to test copying from a SCSI disk on the same bus as the
> tape drive.
Done (tar c/tar d), no corruption.
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
> problems: just _how_ high woul dyou move it? Would it potentially disturb
> an application that opens thousands of files, and knows that they get
> consecutive file descriptors? Which is _legal_ and well-defined in UNIX.
Only if you close them before. The process may have been started with
arbi
> It is unfortunate that this could not have been resolved in a more mature
> manner. Saying "I don't like the way somebody is doing something. I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptable. It would have been nice if you'd
> Is blackbox broken? Or is this a kernel bug? Or a bug in the nvidia
> drivers?
> I hope you can fix it (if it is a kernel bug)...
Only Nvidia can help you. Reproduce the problem from a boot where the nvidia
drivers have never been loaded and then its interesting. Is the box stable
with 2.2 ?
Patrick Mochel <[EMAIL PROTECTED]> writes:
> > > IMHO the pm interface should be split up as following:
> >
> > Nobody has disagreed: therefore this separation must be perfect ;-)
>
> I once heard that patience is a virtue. :)
>
> > > (1) Battery status, power status, UPS status polli
[esr]
> > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig
>arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart
>arch/arm/def-configs/shark
[jgarzik]
> typo, that should be ...YMFPCI.
Actually it's not a typo (although the fix is the same). The old
"SB-c
On Thu, Apr 19 2001, AJ Lewis wrote:
> It is unfortunate that this could not have been resolved in a more mature
> manner. Saying "I don't like the way somebody is doing something. I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptab
On Thu, 19 Apr 2001, AJ Lewis wrote:
> It is unfortunate that this could not have been resolved in a more mature
> manner. Saying "I don't like the way somebody is doing something. I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not accepta
AJ Lewis wrote:
> It is unfortunate that this could not have been resolved in a more mature
> manner. Saying "I don't like the way somebody is doing something. I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptable. It would have be
Hi there,
when I have given my computer a 'quite heavy load' in X, it will sometimes
suddenly, without much reason at that moment itself, stop working... Ie,
the 'stop' itself can happen when the computer isn't even being worked on,
but five minutes after I've done some video editing (using a DC1
Hello,
After downloading latest 2.4.3-ac9 kernel and compiling it I found
that when I insert the i2c-matroxfb module, the modprobe utility
completely monopolize the system during about a minute everything gets
really slow and it seems that it do something on the virtual consoles
d
It is unfortunate that this could not have been resolved in a more mature
manner. Saying "I don't like the way somebody is doing something. I won't
bother to talk to them about it, I'll just flame them and try to undermine
their work." is not acceptable. It would have been nice if you'd actuall
On Thu, 19 Apr 2001, Linus Torvalds wrote:
>
>
> On Thu, 19 Apr 2001, Alexander Viro wrote:
> >
> > Ehh... Non-lazy variant is just read() and write() as down_failed() and
> > up_wakeup() Lazy... How about
>
> Looks good to me. Anybody want to try this out and test some benchmarks?
Ugh. It
David Woodhouse <[EMAIL PROTECTED]>:
>
> [EMAIL PROTECTED] said:
> > I read this as "I haven't fixed the problem because..." not as
> > "Don't fix the problem." Please be more explicit next time so I won't
> > step on your toes?
>
> "This is not a problem, please don't \"fix\" it".
But it i
On Sat, Apr 14, 2001 at 04:42:54PM +0200, Kurt Roeckx wrote:
> While running 2.4.3, I saw the following message a few times:
>
> KERNEL: assertion (tp->lost_out == 0) failed at
> tcp_input.c(1202):tcp_remove_reno_sacks
I've been running tcpdump for some time, and get the message 2
times again to
On Thu, Apr 19, 2001 at 10:21:14AM +0200, Helge Hafting wrote:
> A program may know its own access pattern, but it don't usually know
> future access patterns. Well, backing up the entire fs could benefit
> from a something like this, you probably won't need the backup again
> soon. But this is
David Woodhouse <[EMAIL PROTECTED]>:
>
> > -# CONFIG_MTD_SBC_MEDIAGX is not set
> > -# CONFIG_MTD_ELAN_104NC is not set
> > -# CONFIG_MTD_SA1100 is not set
> > -# CONFIG_MTD_DC21285 is not set
> > -# CONFIG_MTD_CSTM_CFI_JEDEC is not set
> > # CONFIG_MTD_JEDEC is not set
> > # CONFIG_MTD_MIXMEM
[EMAIL PROTECTED] said:
> I read this as "I haven't fixed the problem because..." not as
> "Don't fix the problem." Please be more explicit next time so I won't
> step on your toes?
"This is not a problem, please don't \"fix\" it".
--
dwmw2
-
To unsubscribe from this list: send the line
On Thu, 19 Apr 2001, Andreas Dilger wrote:
> Al, you write:
> > Erm... Folks, can ->s_inode_size be not a power of 2? Both
> > libext2fs and kernel break in that case. Example:
> >
> > dd if=/dev/zero of=foo bs=1024 count=20480
> > mkfs -I 192 foo
>
> I had always assumed that it would be
In article <9bn3sr$fer$[EMAIL PROTECTED]>,
Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>
>What you can do is what strace does: insert a loop instruction after
>the fork or clone call and remove that when the call returns.
You're probably even better off just intercepting the fork, turning it
into
Russell King <[EMAIL PROTECTED]>:
> On Thu, Apr 19, 2001 at 01:19:44PM -0400, Eric S. Raymond wrote:
> > The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
> > source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo
> > involving CONFIG_SOUND_YMPCI does
Hi Linus,
The following patch fixes the OOM deadlock condition caused by
prune_icache(), and also improves its performance significantly.
The OOM deadlock can happen because prune_icache() tries to sync _all_
dirty inodes (under PF_MEMALLOC) on the system before trying to free a
portion of the
Hi
For some reason this one didn't make it through in the first try ;-(
Jes
Hi
I would like to announce the creation of the openlvm mailing list for
discussion about maintenance and further development of the Linux
Logical Volume Manager (LVM).
The new mailing list is named linux-openlvm a
> -# CONFIG_MTD_SBC_MEDIAGX is not set
> -# CONFIG_MTD_ELAN_104NC is not set
> -# CONFIG_MTD_SA1100 is not set
> -# CONFIG_MTD_DC21285 is not set
> -# CONFIG_MTD_CSTM_CFI_JEDEC is not set
> # CONFIG_MTD_JEDEC is not set
> # CONFIG_MTD_MIXMEM is not set
> # CONFIG_MTD_OCTAGON is not set
> # CO
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 12 Apr 2001, Philippe Troin wrote:
>
> > Apt I guess ? It has a very strange behavior when backgrounded...
>
> Not really, just want it tries to run dpkg it hangs.
>
> > > The last read was after the process was forgrounded. The read waits
> > >
On Thu, Apr 19, 2001 at 01:19:44PM -0400, Eric S. Raymond wrote:
> The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
> source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo
> involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
>
Al, you write:
> Erm... Folks, can ->s_inode_size be not a power of 2? Both
> libext2fs and kernel break in that case. Example:
>
> dd if=/dev/zero of=foo bs=1024 count=20480
> mkfs -I 192 foo
I had always assumed that it would be a power-of-two size, but since it
is an undocumented option
Pavel Roskin wrote:
...
>
> There is another interesting line in the log that you didn't quote. The
> driver actually knows about DMA 3:
>
> 0x378: ECP settings irq=7 dma=3
The parport code only uses DMA when told by the user, so
insmod parport_pc dma=auto
should to the trick. Parport
On Thu, 19 Apr 2001, Alexander Viro wrote:
>
> Ehh... Non-lazy variant is just read() and write() as down_failed() and
> up_wakeup() Lazy... How about
Looks good to me. Anybody want to try this out and test some benchmarks?
There may be problems with large numbers of semaphores, but hopefully
On Thu, 19 Apr 2001, Linus Torvalds wrote:
>
>
> On Thu, 19 Apr 2001, Alexander Viro wrote:
> >
> > I certainly agree that introducing ioctl() in _any_ API is a shootable
> > offense. However, I wonder whether we really need any kernel changes
> > at all.
>
> I'd certainly be interested in s
Andreas Dilger <[EMAIL PROTECTED]>:
> Could you make a list that splits the symbols up by each of the above
> failure conditions? It would make the task of deciding how to fix the
> "problem" more apparent.
There are 32 possible categories. I need to eyeball them and decide which
ones are signi
Pavel Roskin wrote:
>
> Hello!
>
> I've compiled 2.4.3-ac9 with support for PNP BIOS. I understand that this
> is a new feature experimental and the feedback is requested.
>
> The setting is BIOS is to use irq 7 and dma 3. I normally use "options
> parport_pc io=0x378 irq=7 dma=3" in /etc/modul
The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo
involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
is never set in these files.
This completely eliminates one class of dea
Thank you. It is true all I want to do is help the community. I feel as
alot of people do XFree86 can not meet the needs of the community. It is
very sad that people feel that no amount of people in the open source
community can make code of the same or better quality as XFree86 in a
shorter peri
Go on. Tell me this isn't an error...
CONFIG_ARCH_CLPS7110: arch/arm/kernel/arch.c
CONFIG_ARCH_CLPS711X: arch/arm/Makefile arch/arm/config.in arch/arm/kernel/Makefile
arch/arm/kernel/entry-armv.S arch/arm/kernel/debug-armv.S arch/arm/def-configs/ebsa110
arch/arm/def-configs/footbridge arch/arm
> > libc is entitled to, and most definitely does exactly that. Take a look at
> > things like gethostent, getpwent etc etc.
>
> Ehh.. I will bet you $10 USD that if libc allocates the next file
> descriptor on the first "malloc()" in user space (in order to use the
> semaphores for mm protection
On Thu, Apr 19, 2001 at 09:01:53PM +0900, Takanori Kawano wrote:
>
> When I ran raw I/O SCSI read/write test with 2.4.1 kernel
> on our IA64 8way SMP box, kernel paniced and following
> message was displayed.
Could you try again with 2.4.4pre4 plus the below patch?
ftp://ftp.us.kerne
NIIBE Yutaka wrote:
>
> Sometime, we have setting like following (say, in the migration
> process of changing IP networks, or perhaps wrong way of load
> balancing):
>
> +--+
> |eth0 eth1 |
> +--+
>| |
> ---+---+
>
> Curr
On Thu, Apr 19, 2001 at 03:25:33PM +0200, Martin Buck wrote:
> I'm getting strange Oopses with 2.2.17 on an AMD Athlon 1.2 GHz machine.
> [...]
BTW, I didn't mention it explicitly, but this kernel is *not*
Athlon-optimized (since I used it for several months on a P II and IIRC,
2.2.17 didn't offe
udma 5 is ata100 udma4 is 66 so it's seeing your disk fine...
as far as the 27MB/s goes, it actually testing the disk and that's
what it got for throughput... that's acutally a pretty good number, on the
diamondmax 80 I get 23MB/s
/dev/hde:
Model=Maxtor 98196H8, FwRev=ZAH814Y0, SerialNo=V80H9Y
On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
> I'm at 2 days uptime now, and have not seen the process-table-hang.
> Looks like this fixed it. Previously I would get a hang in the first
> day or so. I'm using your alpha-numa-3 and rwsem-generic-4 against
> 2.4.4pre3.
good, than
Linus Torvalds wrote:
>
> On Thu, 19 Apr 2001, Abramo Bagnara wrote:
> >
> > > [ Using file descriptors ]
> >
> > This would also permit:
> > - to have poll()
> > - to use mmap() to obtain the userspace area
> >
> > It would become something very near to sacred Unix dogmas ;-)
>
> No, this is NO
On Thu, 19 Apr 2001, Alan Cox wrote:
> > can libraries use fast semaphores behind the back of the user? They might
> > well want to use the semaphores exactly for things like memory allocator
> > locking etc. But libc certainly cant use fd's behind peoples backs.
>
> libc is entitled to, and mos
Hi!
Both kernel 2.4.2 and 2.4.3 have an error in handling magneto-
optical disks (MOs) with 2048-byte blocks when they are formatted
with FAT.
Conditions
--
- Kernel 2.4.2 or 2.4.3 (most likely ALL 2.4.x kernels)
- MO with 2048-byte blocks (e.g. 3.5" 640 MB)
Bob McElrath [[EMAIL PROTECTED]] wrote:
> Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
> >
> > So please try to reproduce the hang with 2.4.4pre3 with those two
> > patches applied:
> >
> >
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
> >
Praveen Rajendran wrote:
> hi
>
> I am working on a kernel module which requires the addition of a large
> number of kernel timers to expire statistical values ( including time
> ) maintained in a table.
>
> One alternative would be to use a single timer and traverse the entire
> table and use t
On Thu, Apr 19, 2001 at 04:46:03PM +0200, David Balazic wrote:
> Vojtech Pavlik ([EMAIL PROTECTED]) wrote :
>
> > On Wed, Apr 18, 2001 at 10:21:53PM -0400, Manuel Ignacio Monge Garcia wrote:
> >
> > > El Mié 18 Abr 2001 15:16, escribiste:
> > > > I don't know about other possible problems wit
Helge Hafting wrote:
> Jeremy Jackson wrote:
>
> > currently all the kernel's heuristics are feed-back control loops.
> > what you are asking for is a feed-forward system: a way for the application
> > to tell kernel "I'm only reading this once, so after I'm done, throw it out
> > straight away"
On Thu, 19 Apr 2001, Abramo Bagnara wrote:
>
> > [ Using file descriptors ]
>
> This would also permit:
> - to have poll()
> - to use mmap() to obtain the userspace area
>
> It would become something very near to sacred Unix dogmas ;-)
No, this is NOT what the UNIX dogmas are all about.
When U
-Original Message-
From: Marc Karasek
To: 'Disconnect '
Sent: 4/19/01 11:49 AM
Subject: RE: Bug in serial.c
I have changed everything to point to /dev/ttyS0. The settings in
lilo.conf (I am booting from a floppy to emulate the embedded space) are
all for ttyS0. Lilo pritns to the te
-Original Message-
From: Marc Karasek
To: 'Richard B. Johnson '
Sent: 4/19/01 11:53 AM
Subject: RE: Bug in serial.c
Did something change between 2.4.2 & 2.4.3? Under 2.4.2 I did not have
to init the terminal (are you refering to the host or client side?) and
just accepted the default
On Thu, Apr 19, 2001 at 11:56:01AM -0400, Jeff Garzik wrote:
> Marcus Meissner wrote:
> >
> > Hi,
> >
> > This updates the nm256_audio driver to the 2.4 PCI API.
> >
> > Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop.
>
> "verified" is the really important part with this driver, sinc
We have found that one of our programs can cause system-wide
corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we
run this program, the FPU gives bad results to all subsequent
processes.
We see this problem on dual 550MHz Xeons with 1GB RAM. We have 64 of
these things, and we s
On Thu, 19 Apr 2001, Alon Ziv wrote:
>
> * the userspace struct was just a signed count and a file handle.
The main reason I wanted to avoid a filehandle is just because it's
another name space that people already use, and that people know what the
semantics are for (ie "open()" is _defined_ to
Marcus Meissner wrote:
>
> Hi,
>
> This updates the nm256_audio driver to the 2.4 PCI API.
>
> Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop.
"verified" is the really important part with this driver, since its
really finicky. I have a patch I would love to bounce to you in
private,
On Thu, 19 Apr 2001, Marc Karasek wrote:
> I am doing some embedded development with the 2.4.x series and have noticed
> a few things..
>
[SNIPPED...]
>
> 2) In 2.4.3 the console port using ttySX is broken. It dumps fine to the
> terminal but when you get to a point of entering data (login, c
On Thu, 19 Apr 2001, Marc Karasek did have cause to say:
> 2) In 2.4.3 the console port using ttySX is broken. It dumps fine to the
> terminal but when you get to a point of entering data (login, configuration
> scripts, etc) the terminal does not accept any input.
Most gettys and such take a
Hi,
This updates the nm256_audio driver to the 2.4 PCI API.
Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop.
Ciao, Marcus
Index: drivers/sound/nm256_audio.c
===
RCS file: /build/mm/work/repository/linux-mm/drivers/sound/n
101 - 200 of 284 matches
Mail list logo