On Sat, 14 Oct 2000, Mike A. Harris wrote:
> to know if after installing updated packages, if I'll still be
> able to use a 2.2.x kernel ok, or if I'll have to resort to
> initscript trickery:
Some people get success with the old kernel and the new modutils, others
find that it does not work.
what's needed/where is iBCS for kernel 2.4?
-d
--
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
The 2.4.0test9 Changes file mentions the following and I'd like
to know if after installing updated packages, if I'll still be
able to use a 2.2.x kernel ok, or if I'll have to resort to
initscript trickery:
Will the following work with 2.2.17 as well?
o util-linux 2.10o
On Fri, 13 Oct 2000, Linus Torvalds wrote:
>
>
> On Fri, 13 Oct 2000, David S. Miller wrote:
> >
> > Linus, why did you apply this?
>
> Because sparc is broken anyway, and this way those Makefiles _will_ get
> fixed?
David,
Bart did the ground work and he did mine Makefile.
Neither your or
On Fri, 13 Oct 2000, David S. Miller wrote:
>
> Linus, why did you apply this?
Because sparc is broken anyway, and this way those Makefiles _will_ get
fixed?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Fri, 13 Oct 2000, David S. Miller wrote:
>
> Linus, why did you apply his patch to _only_ reverse the if condition?
>
> What you applied will crash Sparc again, whereas mine does not crash
> the original Sparc case _and_ it fixes Torben's bug too.
Why woul dit crash the sparc?
If it
>From the file Documentation/SubmittingDrivers
What Criteria Determine Acceptance
--
Licensing: The code must be released to us under the GNU public license.
We don't insist on any kind of exclusively GPL licensing,
and if you
I have been fighting with RH 7.0 trying to make it
work with devfs and the lk 2.4 series. This is the
second time round the loop as I did the same with
RH 6.2 .
The /etc/securetty file no longer needs to be changed
but /etc/security/console.perms needs a different
patch to allow non-root users
On Sat, 14 Oct 2000, Andi Kleen wrote:
> That would be weird, because 2.2 does not support loopback creation on
> NFS (and has an explicit check for it)
Hmm, now that you jar my memory, I remember that I had actually loopback
mounted an iso filesystem image on one machine and then NFS exported
Alan Cox wrote:
> > 'Technology Push' argument - and it shouldn't be that hard. Write some
> > articles on how Linux is innovating, and how Cisco and others are standing
> > in the way of progress.
>
> Cisco are already acting on this issue. No point clobbering them
>
> Alan
AFAIK, Cisco has
On Fri, Oct 13, 2000 at 08:56:51PM -0400, Mike A. Harris wrote:
> On Sat, 14 Oct 2000, bert hubert wrote:
[snip]
> >Well, I think that we need to make some kind of PR push about ECN. Linux
> >right now has enough clout and respect to be able to be used as a
> >'Technology Push' argument - and it
Linus, why did you apply this? It was totally untested and breaks
both Sparc builds. I was going to work on fixing it and then submit
it to you tonight.
Please, people, submit Sparc patches to me when possible. This makes
my life a lot simpler as I can sanity check all submissions. A lot of
Date: Fri, 13 Oct 2000 12:14:29 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
On Fri, 13 Oct 2000, Torben Mathiasen wrote:
>
> Yes it works, its not all that different from my patch ;).
Yeah.
The thing I actually cared most about was the comment, which makes the
I'm just wondering if I'm the only person who has had problems with
2.4.0-test9 recording on ide-scsi cdr's?
Nobody has posted anything about it and the test10-prex changefiles don't
mention it. cdrecord reports very weird results when scanning the scsi
bus whereas dmesg shows what one would
Is there anything besides /linux in the root? Sounds like init is
dynamic and needs the linker and libc. Make sure init is static.
robert
* Paul Powell ([EMAIL PROTECTED]) [001013 17:18]:
> Hello,
>
> I am attempting to move all of the root files and
> folders into a single directory /linux
On Fri, Oct 13, 2000 at 06:36:31PM -0700, Wayne Whitney wrote:
> Also, I should mention that several months ago, I was doing the exact same
> thing on two different machines and similarly my process on the client
> machine got stuck in a disk wait. I didn't look into the problem or
> record any
- pre3:
- update email address of Joerg Reuter
- Andries Brouwer: spelling fixes, missing atari brelse(), breada() fix
- Geert Uytterhoeven: used named initializers for "struct console".
- Carsten Paeth: ISDN capifs - iput() only once.
- Petr Vandrovec: VFAT short name
On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote:
> Andi Kleen wrote:
> >
> > On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote:
> > > Andi Kleen wrote:
> > > >
> > >
> > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > > > from disk absolute to
On Fri, 13 Oct 2000, Brian Gerst wrote:
>
> Also, Could somebody who has a machine with a known buggy processor give
> this patch a try?
I like the patch. Would you mind re-writing the exception handling the
other way around, though:
Instead of doing it like this:
+ __asm__
On Fri, 13 Oct 2000, Ben LaHaise wrote:
>
> Hey folks
Me likee.
This looks much nicer. The hack turned into something that looks quite
ddesigned.
Ingo, I'd like you to comment on all the PAE issues just in case, but I
personally don't have any real issues any more. Small nit: I dislike the
Hi all,
[ My apologies if this is a duplicate; I tried sending this a week ago,
but I didn't see my message in the mailing list archives, so I assume that
it did not go through for some reason . . . ]
This is my first time posting a possible kernel bug, so I hope I get
everything right; I am
I posted the following message here some weeks ago.
I formally apologize to George France, and to the list for my message,
and formally retract it.
The quotation in my message was my own, personal interpretation;
George France did not say those words.
I certainly never intended to misrepresent
On Fri, 13 Oct 2000, Alan Cox wrote:
> > writer might be OK, but AFAICS there is nothing of that sort in the
> > tree. We have such spinlocks, but I don't see how to apply that idea to
> > semaphores. Besides, it ought to be small - every struct file will have to
> > contain such beast.
>
>
Daniel/Linux,
Brian Rayve from Malinkrodt & Malinkrodt has been assigned the Tux 2
Patent analysis and will have a preliminary infringment analysis
sometime next week that will be posted to this list when it is
available. He has obtained the NetApp patents and is reviewing them and
preparing
> 'Technology Push' argument - and it shouldn't be that hard. Write some
> articles on how Linux is innovating, and how Cisco and others are standing
> in the way of progress.
Cisco are already acting on this issue. No point clobbering them
Alan
-
To unsubscribe from this list: send the line
On Sat, 14 Oct 2000, bert hubert wrote:
>> > In other words, being able to just turn on ECN for localhost and your
>> > internal network isn't likely to be terribly useful.
>>
>> Being able to turn ECN on/off for specific routes would be very
>> useful. Currently we have to turn ECN off for
"Jeff V. Merkey" wrote:
>
> "David S. Miller" wrote:
> >
> >Date:Tue, 10 Oct 2000 00:44:58 +0200
> >From: "Andi Kleen" <[EMAIL PROTECTED]>
> >
> >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> >> I dont actually know a CPU that doesnt have one in SMP mode.
"Jeff V. Merkey" wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > "David S. Miller" wrote:
> > >
> > >Date:Tue, 10 Oct 2000 00:44:58 +0200
> > >From: "Andi Kleen" <[EMAIL PROTECTED]>
> > >
> > >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > >> I dont
"David S. Miller" wrote:
>
>Date:Tue, 10 Oct 2000 00:44:58 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
>> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
>> behind an I/O
Date:Fri, 13 Oct 2000 20:49:08 -0400
From: Wakko Warner <[EMAIL PROTECTED]>
Doesn't boot on alpha systems with pci-pci bridges. I sent a
report about this a couple days ago and noone responds.
Richard Henderson knows about this bug and it requires quite a bit of
painful
This patch makes the write-protect test use the normal exception
handling mechanism. This removes the need for the special case check in
the page fault handler. The only concern I have is because of this
comment:
/*
* Beware: Black magic here. The printk is needed here to flush
* CPU state
Doesn't boot on alpha systems with pci-pci bridges. I sent a report about
this a couple days ago and noone responds.
> There's a test10-2 out there.
>
> Notable change to people Cc'd on this mail: this contains the fix for the
> vmalloc() and ioremap() race condition, which deletes the
Hello,
Here is the bug report
When doing "modprobe imm" I get message LOCKUP detected
the trace looks like this:
0: ?? (assume spin_lock_irqsave in blk_get_queue but printed EIP seems to
be sensless - area with no code according to the map file)
1: ll_rw_blk.c: 874
Date:Fri, 13 Oct 2000 15:57:50 -0700
From: Richard Henderson <[EMAIL PROTECTED]>
Either that or adjust how we do atomic operations. I can do 64-bit
atomic widgetry, but not with the code as written.
Ultra can do it as well, and as far as I understand it ia64 64-bit
Hey folks
Below is take two of the patch making pte_clear use atomic xchg in an
effort to avoid the loss of dirty bits. PAE no longer uses cmpxchg8 for
updates; set_pte is two ordered long writes with a barrier. The use of
long long for ptes is also removed; gcc should generate better code
Hello,
I am attempting to move all of the root files and
folders into a single directory /linux on the root
file system. I then use the kernel parameter
init=/linux/sbin/init to get things rolling but the
kernel panics.
When I boot linux, everything seems to work ok until
the kernel tries to
On Fri, Oct 13, 2000 at 01:43:09PM +0100, Mike Jagdis wrote:
> > In other words, being able to just turn on ECN for localhost and your
> > internal network isn't likely to be terribly useful.
>
> Being able to turn ECN on/off for specific routes would be very
> useful. Currently we have to turn
On Fri, 13 Oct 2000, jamal wrote:
>
> This is in addition to the debug statements from the previous email
> Weirder results (like bus 0x0a)
Ok, thanks - this part didn't get anything new, the bus numbers are just
different due to the re-allocation, the actual bus windows are the same
broken
> > I agree. I would expect it to be 8 instead of 32.
> > Actually I just checked on a new Thinkpad T20 with a TI
> > PCI 1450 CardBus controller *on a different OS*
> > and it is 8.
>
> I'll fix it to be 8.
>
> Thanks,
>
> Linus
Well, preferably to what David said:
On Fri, 13 Oct 2000, Dunlap, Randy wrote:
>
> I agree. I would expect it to be 8 instead of 32.
> Actually I just checked on a new Thinkpad T20 with a TI
> PCI 1450 CardBus controller *on a different OS*
> and it is 8.
I'll fix it to be 8.
Thanks,
Linus
-
To unsubscribe
On Fri, 13 Oct 2000, jamal wrote:
>
> On Fri, 13 Oct 2000, Linus Torvalds wrote:>
> > Can you add the same extra debug code that I asked Dag Bakke to add for
> > his problem:
>
> Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular
> On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote:
> > I'm not familiar with yenta controllers/devices,
> > and I'm not trying to throw you a tasty red herring,
> > but...
> >
> > yenta_config_init() does
> > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
> >
> > Is this
I have a program:
#include
#include
#include
int
main() {
DIR *dir = opendir("/uss/zzq/TIDs");
printf("dir = %08lx\n",(int)dir);
}
which fails to work correctly under the development version of libc.
brian@remo brian>gcc foo.c(redhat 6.2 libc)
brian@remo brian>./a.out
dir =
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Oh, also, can you try to see what happens if you change the define for
>
> #define pcibios_assign_all_busses() 0
>
> to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure
> all buses, regardless of whether they have
On Fri, Oct 13, 2000 at 11:47:55PM +0100, Alan Cox wrote:
> Then we need to use locking to protect the rss since on a big 64bit box
> we can exceed 2^32 pages in theory and probably soon in practice.
Either that or adjust how we do atomic operations. I can do
64-bit atomic widgetry, but not
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Can you add the same extra debug code that I asked Dag Bakke to add for
> his problem:
>
> -- snip from another email, because I'm lazy ---
>
> Please add a debug printk() to drivers/pci/setup-res.c to the very end of
> pci_assign_bus_resource(),
On Fri, Oct 13, 2000 at 02:25:45PM -0700, Linus Torvalds wrote:
> And even on alpha, a 32-bit atomic_t means we cover 45 bits of virtual
> address space, which, btw, is more than you can cram into the current
> three-level page tables, I think.
While that's true of Alpha, it's not true of Ultra
> If this is done, I recommend we immediately mark it as deprecated and likely
> to go away soon. It's better to get people to upgrade their IOS than to
> force kludges. If they have an old IOS, this is probably one of several
> issues that need fixing.
I have no hope of Linuxtoday fixing
Harald Welte <[EMAIL PROTECTED]> writes:
> On Thu, Oct 12, 2000 at 11:59:51PM +0200, J . A . Magallon wrote:
> > Hi, everybody.
> >
> > Kernel 2.2.18-pre15 compiles fine under gcc-2.95.2. It is just plain
> > 2.2.17 with Alan's patch to 18-pre15.
> >
> > I downloaded the gcc-2.96 rpms from
> On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote:
> > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the
> > ultrsparc/alpha ?
>
> It is not.
Then we need to use locking to protect the rss since on a big 64bit box
we can exceed 2^32 pages in theory and
I have tested Linus' patch and it makes a difference:
cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
Found 06:00 [115d/0003] 000200 00
bus res 0 1200 1c00-1fff
bus res 1 200 2000-23ff
bus res 2 100 1800-18ff
bus res 0 1200 1c00-1fff
bus res 1 200
Andi Kleen wrote:
>
> On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote:
> > Andi Kleen wrote:
> > >
> >
> > > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > > from disk absolute to relative). When you change it now (before 2.4.0)
> > > it is relatively painless.
kernel wrote:
>
>
> Caution is advised when depending upon crypto systems that use relative
> block numbers as IV. The security may not be a strong as hoped.
> There are some who believe that "not unique" IVs (across multiple
> filesystems) facilitates some methods of cryptanalysis.
>
Do you
> I've found the problem. This type of loop does not work:
>
> do {
> alarm(t);
> read(fd);
> if (EINT)
>exception();
> else
>alarm(0);
> } while (data);
>
> There are some semantics here that differ from other *nix where this
> works. The read() won't come out
> writer might be OK, but AFAICS there is nothing of that sort in the
> tree. We have such spinlocks, but I don't see how to apply that idea to
> semaphores. Besides, it ought to be small - every struct file will have to
> contain such beast.
It would mean a check when putting a file handle,
Apologies in advance if this is a known problem. I've been away from kernel
hacking for about three years and just re-subscribed to lkml a couple of weeks
ago, so I may have missed something about this. But I haven't been able to find
anything in the documentation or on lkml about it. If
On Fri, Oct 13, 2000 at 02:44:32AM +0200, FORT David wrote:
>
> USB still have problems, when starting to grab with my ov511 webcam i got the
> attached oops. This bug appeared
> in test9-preX(X beeing at least > 2) series. Some people have claimed that
> test10-pre1 fixed the problem, but
> the
On Fri, Oct 13, 2000 at 01:52:12PM -0400, Claude LeFrancois (LMC) wrote:
> Hello,
>
> I had the same problem with the USB core driver compiled statically into
> the kernel 2.4.0-test10pre1. If I get the whole USB distribution
> compiled as a modules, everything works fine. Here is the content
If this is done, I recommend we immediately mark it as deprecated and likely
to go away soon. It's better to get people to upgrade their IOS than to
force kludges. If they have an old IOS, this is probably one of several
issues that need fixing.
-d
Mike Jagdis wrote:
> > Right you are, both
Date: Fri, 13 Oct 2000 12:45:47 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
> It might make more sense to just make rss an atomic_t.
Can we always be sure the rss will fit in an atomic_t - is it >
32bits on the ultrsparc/alpha ?
Yes, this issue occurred to me last night as
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote:
> I'm not familiar with yenta controllers/devices,
> and I'm not trying to throw you a tasty red herring,
> but...
>
> yenta_config_init() does
> config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
>
> Is this writing to the CardBus
Michal Jaegermann wrote:
>
> On UP1100 Alpha with an AGP slot and "Advanced Micro Devices [AMD]
> AMD-751 [Irongate] System Controller" an attempt to use 'agpgart'
> support ends up with an oops. I tried 2.2.17 and 2.2.18pre15 kernels.
> With CONFIG_AGP=y and CONFIG_AGP_AMD=y resulting kernel
On Fri, 13 Oct 2000 13:38:19 Chmouel Boudjnah wrote:
> "J . A . Magallon" <[EMAIL PROTECTED]> writes:
>
> > I have a little problem when compiling new kernels. I run Mandrake 7.1
> > with many many updates (its almost 7.2beta).
>
> install the last egcs package from 7.2b and compile with kgcc
On Fri, Oct 13, 2000 at 02:23:44PM -0700, Linus Torvalds wrote:
> ... but on a 3-level page table (whether with PAE on x86 or on alpha),
> you could easily just decide to limit the vmalloc() area to a a gigabyte
> or two and handle it with just one PGD entry..
I'm undecided. For normal usage,
On Fri, 13 Oct 2000, Jakub Jelinek wrote:
> On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote:
> > On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote:
> > > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the
> > > ultrsparc/alpha ?
> >
> > It
On Fri, 13 Oct 2000, Richard Henderson wrote:
> On Fri, Oct 13, 2000 at 12:22:35PM -0700, Linus Torvalds wrote:
> > The PGD is 1024 entries, and the last one is used by the self-mapping
> > stuff. But the VMALLOC area is NOT there ...
>
> Ok, I was slightly confused. Yes, the vptb is at
I'm not familiar with yenta controllers/devices,
and I'm not trying to throw you a tasty red herring,
but...
yenta_config_init() does
config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
Is this writing to the CardBus bridge or to the device's
CacheLineSize register?
If the latter, and given
On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote:
> On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote:
> > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the
> > ultrsparc/alpha ?
>
> It is not.
It is not even 32bit on sparc32 (24bit only).
On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote:
> Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the
> ultrsparc/alpha ?
It is not.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Fri, 13 Oct 2000, J. Scott Kasten wrote:
> I've found the problem. This type of loop does not work:
>
> do {
> alarm(t);
> read(fd);
> if (EINT)
>exception();
> else
>alarm(0);
> } while (data);
>
> There are some semantics here that differ from other *nix
On Fri, 13 Oct 2000, Benjamin Herrenschmidt wrote:
> >Or, more general, treat [PCI] I/O space similar to [PCI] memory space. Just
> >like we must use ioremap() for memory space:
> >
> >cookie = ioremap(memory_space_address, size);
> >x = readb(cookie+offset);
> >
> >we could have
On Fri, Oct 13, 2000 at 04:28:30AM +0200, Andi Kleen wrote:
(snip)
> 2.4 has already broken backwards compatibility to 2.2 (IV changed
> from disk absolute to relative). When you change it now (before 2.4.0)
> it is relatively painless. I think the change is a good idea.
>
Caution is advised
I've found the problem. This type of loop does not work:
do {
alarm(t);
read(fd);
if (EINT)
exception();
else
alarm(0);
} while (data);
There are some semantics here that differ from other *nix where this
works. The read() won't come out when the alarm comes, and
gcc -D__KERNEL__ -I/tmp/romieu/tmp/linux-2.4.0-test10-pre2/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -march=i686 -fno-strict-aliasing
-DMODULE -DMODVERSIONS -include
/tmp/romieu/tmp/linux-2.4.0-test10-pre2/include/linux/modversions.h -c -o rcpci45.o
rcpci45.c
In
Hi!
Here is more updated work on the vgacon to fbcon to vgacon again code. I
almost got it. I just need to figure out how to free up the resources from
the fbdev drivers I tried it out on. I have attemped on the G400 matrox
driver and the vga16 driver. Both give a : Device or resource busy
with 2.4.0test10-pre2
ksymoops 2.3.3 on i686 2.4.0-test10. Options used
-v /usr/src/linux/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test10/ (default)
-m /usr/src/linux/System.map (default)
Oct 13 20:28:58
On UP1100 Alpha with an AGP slot and "Advanced Micro Devices [AMD]
AMD-751 [Irongate] System Controller" an attempt to use 'agpgart'
support ends up with an oops. I tried 2.2.17 and 2.2.18pre15 kernels.
With CONFIG_AGP=y and CONFIG_AGP_AMD=y resulting kernel gets stuck
after oops and does not
On Fri, 13 Oct 2000, John Williams wrote:
> This means to add ipx to the kernel, I have to rebuild the entire kernel
> and boot with it in order to satisfy the dependancies. I cannot just
> compile it as a module and add it because it has non-modular
dependancies.
I encountered this same
On Fri, Oct 13, 2000 at 12:22:35PM -0700, Linus Torvalds wrote:
> The PGD is 1024 entries, and the last one is used by the self-mapping
> stuff. But the VMALLOC area is NOT there ...
Ok, I was slightly confused. Yes, the vptb is at 0xfffe
not 0xfe00. The bit I was
About a year ago there was a short thread about unresolved symbols in the
ipx module, which doesn't appear to have come to a solution. I have just
had the same problem, and have some new information to add.
(kernel 2.2.16 on Redhat 6.2)
The problem: "depmod -ae" says
depmod: *** Unresolved
It's likely the megaraid driver. Try the megaraid driver that's in the
latest 2.2.18pre.
Thanks,
Matt
-Original Message-
From: Greg Hennessy [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 13, 2000 2:59 PM
To: [EMAIL PROTECTED]
Subject: Dell smp won't boot
One of my dual cpu dell
Timur Tabi wrote:
> I understand that a normal virtual address (i.e. a pointer) can only address a
> single 32-bit (4GB) memory block. My point was that by also using more than
> one 16-bit selector, you can have multiple 4GB areas. So for instance,
> 1000: can point to one physical
One of my dual cpu dell server running 2.2.15 has stopped booting.
It gets part way through the boot process and rints
wait_oin_bh, cpu 1
irq: 0 [0 0]
bh: 1 [1 0]
<[c010aefd]> <[c0119ecf]> <[c011a029]> <[c0113ad0]> <[c010933c]>
and repeats. Might this be a software problem, or should I simply
On Fri, 13 Oct 2000, Timur Tabi wrote:
> ** Reply to message from Alexander Viro <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 15:25:31 -0400 (EDT)
>
>
> > Ditto with PAE: 16:32->32->36.
> > In _all_ cases you are limited by the size of linear address. I.e. all
> > address modes are limited to
On Fri, 13 Oct 2000 13:37:21 Andre Tomt wrote:
>
> I have to be wicked crazy - but:
> Linux version 2.2.18pre15 (root@juce) (gcc version 2.97 20001010
> (experimental)) #7 Tue Oct 10 20:18:58 CEST 2000
>
> It seems to "work", but it hasn't been put under stress, yet.
> The reason I tried the
On Fri, 13 Oct 2000, Timur Tabi wrote:
> I understand that a normal virtual address (i.e. a pointer) can only address a
> single 32-bit (4GB) memory block. My point was that by also using more than
> one 16-bit selector, you can have multiple 4GB areas. So for instance,
> 1000: can
** Reply to message from Alexander Viro <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
15:25:31 -0400 (EDT)
> Ditto with PAE: 16:32->32->36.
> In _all_ cases you are limited by the size of linear address. I.e. all
> address modes are limited to 4Gb. All you can get from PAE is placing of
> these 4Gb
On Fri, 13 Oct 2000, Timur Tabi wrote:
> ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 20:44:19 +0200 (CEST)
>
>
> > processes are not limited to a single segment, eg. Wine uses nonstandard
> > segments. But as i said, using multiple segments does not let you
I'm working with test6 on an embedded QED MIPS arch in big endian mode. I
have run into some bizarre socket problems that appear to affect both udp
and tcp transport. Applications actively using sockets (examples, ftp,
tftp, others...) will unexpectedly stop receiving data on the socket, even
** Reply to message from Brian Gerst <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
15:07:42 -0400
> You missed the point. The layering on the X86 memory managment is such:
>
>Segment
> |
> Virtual Address<- limited to 32 bits
> |
> Physical Address
>
> Segmentation never
In article <[EMAIL PROTECTED]>,
Richard Henderson <[EMAIL PROTECTED]> wrote:
>On Fri, Oct 13, 2000 at 08:15:46PM +0400, Ivan Kokshaysky wrote:
>> On Thu, Oct 12, 2000 at 01:18:53PM -0700, Linus Torvalds wrote:
>> > See the arch/x86/mm/fault.c changes to see what arch-specific changes this
>> >
On Fri, 13 Oct 2000, Chris Swiedler wrote:
>
> Why is it that a user process can't intentionally switch segments?
> Dereferencing a 32-bit address causes the address to be calculated using the
> "current" segment descriptor, right? It seems to me that a process could set
> a new segment
On Fri, Oct 13, 2000 at 10:27:05AM -0700, Dunlap, Randy wrote:
> > I tried:
> >
> > setpci -s 00:07.2 latency_timer=20
> > setpci -s 00:07.2 latency_timer=40
> > setpci -s 00:07.2 latency_timer=80
> >
> > but without effect. However, the USB device doesn't have a latency
> > timer, so
On Fri, 13 Oct 2000, Torben Mathiasen wrote:
>
> Yes it works, its not all that different from my patch ;).
Yeah.
The thing I actually cared most about was the comment, which makes the
patch palatable to me.
Linus
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, Oct 13, 2000 at 09:54:14AM -0700, Richard Henderson wrote:
> You shouldn't have needed any changes at all to work.
But without that change I've got oopses (fortunately not fatal)
in swapon and modprobe.
> The synchronization we already do for the vptb also
> takes care of vmalloc.
>
Timur Tabi wrote:
>
> ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 20:44:19 +0200 (CEST)
>
> > processes are not limited to a single segment, eg. Wine uses nonstandard
> > segments. But as i said, using multiple segments does not let you out of
> > 32 bits of
On Fri, 13 Oct 2000, Linus Torvalds wrote:
>
> Can you add the same extra debug code that I asked Dag Bakke to add for
> his problem:
Oh, also, can you try to see what happens if you change the define for
#define pcibios_assign_all_busses() 0
to a 1 in include/asm-i386/pci.h?
On Fri, 13 Oct 2000, Alan Cox wrote:
> > 1) one process does read() on device, another does revoke()
> > followed by rmmod. Oops - nothing holds module in memory, the first
> > process is executing code from that module (->read(), that is) and
> > we unmap that code.
> >
> > 2) every
On 13 Oct 00 at 13:42, Timur Tabi wrote:
> ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 20:44:19 +0200 (CEST)
> > processes are not limited to a single segment, eg. Wine uses nonstandard
> > segments. But as i said, using multiple segments does not let you out of
On Fri, 13 Oct 2000, Timur Tabi wrote:
> Sure it does, just like segments let 16-bit apps access more than 64KB of
> memory. If you have two selectors, each one can point to a different physical
> base address, and IIRC, the size of the physical address base can be 36 bits.
> That gives you 16
1 - 100 of 369 matches
Mail list logo
