Miguel Armas wrote:
> A couple days ago we installed a Fore 200E ATM card and after getting the
> ATM address using ilmid the machine hangs. The kernel still respond to
> pings, but the userspace is dead.
>
> If we remove SMP support in the kernel everything works fine (but with
> only one CPU)..
Ingo Molnar wrote:
> - probably the most radical solution is what i suggested, to completely
> avoid the unique-mapping of file structures to an integer range, and use
> the address of the file structure (and some cookies) as an identification.
IMO... gross. We do pretty much this exact thing in
Patrick van de Lageweg wrote:
> This patch contains the fix for the atmrefcount problem (noted as a
> critical problem in Ted's todo list). It also has the makefile
> modifications for the firestream driver in a separate email.
Could you please split the two patches so that they're actually inde
First, I'd like to make a couple points about driver style that I'm trying
to move towards with the ATM drivers. You're free to take them or leave
them, but I want to eventually move the tree in this direction.
* I don't like header files that define the registers of the chip - since
the he
H. Peter Anvin wrote:
> I suggested include/kernel and include/arch with include/linux and
> include/asm being reserved for the kernel interfaces (ioctl and their
> structures mostly.)
That sounds good. One other refinement I would like to see is that
architecture specific but always present hea
Alan Cox wrote:
> > Now, I see people trying to introduce the concept of elapsed time into
> > that fix, which smells strongly of hack. How will this hack be cobbled
>
> Actually my brain says that elapsed time based scheduling is the right thing
> to do.
No, Andrea is right here. The argument
Alan Cox wrote:
> > time, but remember that there are two things measured in time here:
> > A. The time for the whole queue of requests to run (this is what Rik is
> > proposing using to throttle)
> > B. The time an average request takes to process.
>
> Your perceived latency is based en
Daniel Quinlan wrote:
> "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
> The web page will list valid version strings.
Ideally this should be overridable for patches marked experimental, since
they might be to some modified kernel. Of course you wo
Alan Cox wrote:
> > Yes, but "how hard is it reasonable for the kernel to try" is based on
> > both items. A good first order approximation is number of requests.
>
> I must strongly disagree with that claim. A request could be 512 bytes or
> 128K.
Yeah, as sct pointed out this gets thorny. F
Alan Cox wrote:
> Humans will generally get a weird report from sending Linus a message wonder
> what all this field stuff is and mail someone else instead.
If they're able to create a patch, hopefully they'd be able to fill in
a simple email template (and I've seen some pretty dim folks manage
Alexander Viro wrote:
> BTW, any bug reports starting with "kernel is x.y.z + FOO42069 + K314 +
> " will be cheerfully flushed down the toilet here,
> no matter what system of dependencies is going to be in place.
Yes, for the stuff discussed on lkml patch dependencies should be
pretty minimal.
James Sutherland wrote:
> In terms of latency, I'd suggest we aim to keep the device in use all the
> time we have outstanding requests: every time the device is ready to
> accept a request, we feed it the "next" one in the queue; until it is free
> again, requests pile up in the queue, being sort
Werner Almesberger wrote:
> Mitchell Blank Jr wrote:
> > Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc
> > open/close) code is pretty suspect.
>
> That's actually a bit of an understatement:
Well, I was trying to be polite to the origin
Jason Slagle wrote:
> It worked fine under 2.3.x and as a matter of fact worked fine under
> 2.4.0-test1-4 I believe.
>
> I don't buy a hardware explination when I've been running this setup for
> well over a year and only just now have problems :)
It's because we've seen it a hundred zillion ti
Linus Torvalds wrote:
> Here's a suggested "good" interface that would certainly be easy to
> implement, and very easy to use, with none of the scalability issues that
> many interfaces have.
I think everyone should take a timeout and look at Solaris 8's /dev/poll
interface. This discussion is r
Linus Torvalds wrote:
> > * it doesn't add extra syscalls
>
> Sure it does.
>
> What do you think ioctl's are?
As I explained a few lines down from where you stopped quoting (and probably
stopped reading) the ioctl() use is just an artifact of Solaris's icky
implementation. It could and sho
Richard B. Johnson wrote:
> > And here is the broken routine:
> >
> > 03f4 :
[...]
> This is not good code. It does the following:
>
> o Gets a parameter off the stack and puts into eax (a pointer).
> o Put the value 1 into ecx.
> o Take a byte from the pointed-to location and pu
[EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be running when the interrupt happened. So
any attempt to access it is 99
[EMAIL PROTECTED] wrote:
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
> > same CPU as the task currently running.
>
> This makes sense. And I wish cpu architects would put a cpu-id
> register som
Dan Aloni wrote:
>
> I've been touring around the kernel sources when I stumbled
> across the uid_hash_find() function (kernel/user.c):
>
> static inline struct user_struct *uid_hash_find(unsigned short uid, unsigned int
>hashent)
Is it just me, or should that be "uid_t" not "unsigned short"?
[EMAIL PROTECTED] wrote:
> 4. Boot Time Failures
[...]
> * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
>more info)
I _highly_ suspect that this is not a 2.4 bug but is instead user error.
I've seen it several times.
On all kernel versions prior to 2.3.11 if you
Rogier Wolff wrote:
> We're trying to make the module refcounting 'secure' against
> concurrent SMP unloads.
>
> For example in net/atm/resources.c:
Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc
open/close) code is pretty suspect. If you want to look through and
liberal
Junfeng Yang wrote:
> [BUG] fore200e_kmalloc can return NULL
> /u2/acc/oses/linux/2.4.1/drivers/atm/fore200e.c:2032:fore200e_get_esi:
>ERROR:NULL:2020:2032: Using unknown ptr "prom" illegally! set by
>'fore200e_kmalloc':2020
I don't see the bug - there is an explicit "if(!prom) return -ENOMEM;"
Andreas Dilger wrote:
> With per-group (or maybe per-bitmap) locking, files could be created in
> parallel with only a small amount of global locking if they are in different
> groups.
...and then we can let the disc go nuts seeking to actually commit all
these new blocks. I suspect that this ch
Wichert Akkerman wrote:
> You are just delaying the problem then, at some point your uptime will
> be large enough that you have run through all 64bit pids for example.
64 bits is enough to fork 1 million processes per second for over
500,000 years. I think that's putting the problem off far eno
David S. Miller wrote:
> - hash = hash ^ (hash >> D_HASHBITS) ^ (hash >> D_HASHBITS*2);
> + hash = hash ^ (hash >> D_HASHBITS) ^
> + (hash >> (D_HASHBITS+(D_HASHBITS/2)));
Two comments:
1. The inode-cache has the exact same problem, but it'll require a lot
of RAM to run
Ted Kremenek wrote:
> Currently we are looking primarily into the
> ioctls in drivers/net,
Just as a small aside, a little over five years ago (wow does time fly!) I
did a manual audit for mistakes like this:
http://lkml.org/lkml/2000/3/7/156
Not sure if that's relevant to your work your not...
Alexander Viro wrote:
> I can see how to implement per-mountpoint variant. However, I'm
> less than enthusiastic about the API side of that and about the
> ugliness it will lead to. It smells like a wrong approach. And
> no, I don't see a good one right now.
Aren't we one day going to have stacka
Greg KH wrote:
> > + /* locate trailng white space */
> > + z = y = x;
> > + while (y - buffer->page < count) {
> > + y++;
> > + z = y;
> > + while (isspace(*y) && (y - buffer->page < count)) {
> > + y++;
> > + }
> > + }
> > + coun
Steven Rostedt wrote:
> In the thread "[RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO
> configurable" I discovered that a C version of find_first_bit is faster
> than the asm version
There are probably other cases of this in asm-i386/bitopts.h. For instance
I think the "btl" instruction is pr
Jon Smirl wrote:
> Do we need to deal with UTF8 here? I did the forward loop because you
> can't parse UTF8 backwards. If UTF8 is possible I need to change the
> pointer inc function.
As others have mentioned there shouldn't be a UTF8 problem with isspace().
However, even if you wanted to scan goi
Still one nitpick:
Jon Smirl wrote:
> + while (isspace(*x) && (x - buffer->page < count))
> + x++;
I think you can just do:
if (count > 0)
while (isspace(*x))
x++;
If the passed-in string was fully whitespace then the trailing-whit
Andi Kleen wrote:
> - it doesn't seem to help that much on modern CPUs with good
> branch prediction and big icaches anyways.
Really? I would think that as pipelines get deeper (although that trend
seems to have stopped, thankfully) and Icache-miss penalties get relatively
larger we'd see unlikel
Richard Henderson wrote:
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int
Stephen C. Tweedie wrote:
> If we want to fix this, let's fix the macros: for example, convert
> EXT3_HAS_COMPAT_FEATURE to be
>
> ( le32_to_cpu(EXT3_SB(sb)->s_es->s_feature_compat) & (mask) )
Of course that's less efficient though since "mask" is probably constant..
so now the endian conve
[EMAIL PROTECTED] wrote:
> SUBJECT:
> Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
>
>
> DRIVER RESULTS:
> Works fine in 2.4.0 kernel.
> Locks up system (no messages/oops/etc.) in 2.4.2-2 kernel (rh 7.1).
> Locks up system (no messages/oops/etc.) in 2.4.2 kernel (w/ or w/o kgdb).
> Loc
Chas.
-Mitch
[PATCH] [ATM] remove firestream.c's aligned_kmalloc()
Signed-off-by: Mitchell Blank Jr <[EMAIL PROTECTED]>
diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
index 9c67df5..df8b0c0 100644
--- a/drivers/atm/firestream.c
+++ b/drivers/atm/firestream.c
@@ -1379,38 +1379
Al Viro wrote:
> At least 3 versions, unless you want to mess with ifdefs to reduce them to
> two.
I don't think you need to do fancy #ifdef's:
static s32 return_eio_32(void) { return -EIO; }
static s64 return_eio_64(void) { return -EIO; }
extern void return_eio_unknown(void); /* Doesn't exist
Linus Torvalds wrote:
> Well, that probably would work, but it's also true that returning a 64-bit
> value on a 32-bit platform really _does_ depend on more than the size.
Yeah, obviously this is restricted to the signed-integer case. My point
was just that you could have the compiler figure out
Al Viro wrote:
> On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
> > The real (but harder) fix for the wasted space issue
> > would be to get the toolchain to automatically combine functions that
> > end up compiling into identical assembly.
>
>
40 matches
Mail list logo
