Re: alpha iommu fixes
Andrea Arcangeli wrote: > On Mon, May 21, 2001 at 04:04:28AM -0700, David S. Miller wrote: > > How many physical PCI slots on a Tsunami system? (I know the > > on tsunamis probably not many, but on a Typhoon (the one in the es40 > that is the 4-way extension) I don't know, but certainly the box is > large. > ES40 has either 8 or 10 PCI slots across 2 PCI buses. And then there's Wildfire - 14 slots per PCI drawer (4 PCI buses) * 2 drawers/QBB * 8 QBBs = 224 PCI slots & 64 PCI buses. BTW, Titan (aka ES45) has 10 slots as well, but with 3 buses instead. - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
Andrea Arcangeli wrote: On Mon, May 21, 2001 at 04:04:28AM -0700, David S. Miller wrote: How many physical PCI slots on a Tsunami system? (I know the on tsunamis probably not many, but on a Typhoon (the one in the es40 that is the 4-way extension) I don't know, but certainly the box is large. ES40 has either 8 or 10 PCI slots across 2 PCI buses. And then there's Wildfire - 14 slots per PCI drawer (4 PCI buses) * 2 drawers/QBB * 8 QBBs = 224 PCI slots 64 PCI buses. BTW, Titan (aka ES45) has 10 slots as well, but with 3 buses instead. - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux scalability?
"David S. Miller" wrote: > Peter Rival writes: > > Really? I just checked and it's still there from what I see. We're talking > > about the Dell 8450/700 w/ IIS & SWC 3.0 result, right? I'm hoping that > > they're deemed NC, but I don't see it yet... > > Sorry, they are there in the table, but marked as NC. > > Maybe you need to hit reload in your browser :-) > Yup, one of them is marked as NC. But the other one is still there (and I hit reload and even shift-reload). So either you're missing the second one or something is not behaving nicely with our web proxies here. While I'd probably be more inclined to believe the latter... ;) - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux scalability?
"David S. Miller" wrote: > J Sloan writes: > > Microsoft finally managed to get a better result using > > an all-out, "bet the farm", "benchmark buster" setup > > with a special web cache in front of iis. > > I haven't heard anyone talk about the fact that their 8-cpu numbers > got disqualified and aren't even mentioned on the SPEC site on the > main tables anymore. > Really? I just checked and it's still there from what I see. We're talking about the Dell 8450/700 w/ IIS & SWC 3.0 result, right? I'm hoping that they're deemed NC, but I don't see it yet... - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux scalability?
David S. Miller wrote: Peter Rival writes: Really? I just checked and it's still there from what I see. We're talking about the Dell 8450/700 w/ IIS SWC 3.0 result, right? I'm hoping that they're deemed NC, but I don't see it yet... Sorry, they are there in the table, but marked as NC. Maybe you need to hit reload in your browser :-) Yup, one of them is marked as NC. But the other one is still there (and I hit reload and even shift-reload). So either you're missing the second one or something is not behaving nicely with our web proxies here. While I'd probably be more inclined to believe the latter... ;) - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux scalability?
David S. Miller wrote: J Sloan writes: Microsoft finally managed to get a better result using an all-out, bet the farm, benchmark buster setup with a special web cache in front of iis. I haven't heard anyone talk about the fact that their 8-cpu numbers got disqualified and aren't even mentioned on the SPEC site on the main tables anymore. Really? I just checked and it's still there from what I see. We're talking about the Dell 8450/700 w/ IIS SWC 3.0 result, right? I'm hoping that they're deemed NC, but I don't see it yet... - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPU hot swap for 2.4.3 + s390 support
Chris Wedgwood wrote: > On Sat, May 05, 2001 at 10:43:27AM -0400, Peter Rival wrote: > > Has anyone looked into memory hot swap/hot add support? > > Adding memory probably isn't going to be too hard... but taking > existing memory off line is tricky. You have to find some way of > finding all the pages that are in use and then dealing with them > appropriately, and when some are locked or contain kernel data this > would be extremely difficult I should think. > Hrmm... I agree this is a hard problem. I know people smarter than I have been thinking about this type of problem at Compaq. While I haven't talked to them directly, my only guess would be that we'd have to hand-rewrite some page tables after copying the page contents to a new area. It's late Saturday and I really haven't thought this through fully, so I'm not even sure that would work, but it's something like how we support replicated text segments on our GS series...don't know why it wouldn't work here. *shrug* > Especially with systems with Chipkill coming out, this would be > great to support... > > Chipkill? > It's the IBM technology that works around bad memory by detecting single-bit errors and removing the chip that caused it from use. I'd think of this as a big hammer version of that in software. Besides, eventually you'll want to replace the DIMM that has the bad chip, and what better way then while the system is still running (as long as it's stable, of course ;) I'm just thinking out loud, so someone can correct me if I'm being loopy... - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPU hot swap for 2.4.3 + s390 support
Has anyone looked into memory hot swap/hot add support? Especially with systems with Chipkill coming out, this would be great to support... - Pete Anton Blanchard wrote: > Hi, > > You can find a new version of the hot swap cpu patch at: > > http://samba.org/~anton/patches/cpu_hotswap-2.4.3-patch > > The version for s390 (you need to first apply the 2.4.3 kernel > patch available on the IBM s390 Linux website) is at: > > http://samba.org/~anton/patches/cpu_hotswap-2.4.3-patch-s390 > > Many thanks to Heiko Carstens <[EMAIL PROTECTED]> for adding > s390 support and fixing a few bugs in the initial implementation. > You should be able to attach and detach CPUs depending on workload > in your s390 Linux guest images :) > > One of the advantages of this patch is that it removes cpu_logical_map() > and cpu_number_map() which people had a tendency to get wrong. > > It should also be easy to support more than BITS_PER_LONG cpus > as there is no concept of online_cpu_map any more. > > Anton > - > 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/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPU hot swap for 2.4.3 + s390 support
Has anyone looked into memory hot swap/hot add support? Especially with systems with Chipkill coming out, this would be great to support... - Pete Anton Blanchard wrote: Hi, You can find a new version of the hot swap cpu patch at: http://samba.org/~anton/patches/cpu_hotswap-2.4.3-patch The version for s390 (you need to first apply the 2.4.3 kernel patch available on the IBM s390 Linux website) is at: http://samba.org/~anton/patches/cpu_hotswap-2.4.3-patch-s390 Many thanks to Heiko Carstens [EMAIL PROTECTED] for adding s390 support and fixing a few bugs in the initial implementation. You should be able to attach and detach CPUs depending on workload in your s390 Linux guest images :) One of the advantages of this patch is that it removes cpu_logical_map() and cpu_number_map() which people had a tendency to get wrong. It should also be easy to support more than BITS_PER_LONG cpus as there is no concept of online_cpu_map any more. Anton - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPU hot swap for 2.4.3 + s390 support
Chris Wedgwood wrote: On Sat, May 05, 2001 at 10:43:27AM -0400, Peter Rival wrote: Has anyone looked into memory hot swap/hot add support? Adding memory probably isn't going to be too hard... but taking existing memory off line is tricky. You have to find some way of finding all the pages that are in use and then dealing with them appropriately, and when some are locked or contain kernel data this would be extremely difficult I should think. Hrmm... I agree this is a hard problem. I know people smarter than I have been thinking about this type of problem at Compaq. While I haven't talked to them directly, my only guess would be that we'd have to hand-rewrite some page tables after copying the page contents to a new area. It's late Saturday and I really haven't thought this through fully, so I'm not even sure that would work, but it's something like how we support replicated text segments on our GS series...don't know why it wouldn't work here. *shrug* Especially with systems with Chipkill coming out, this would be great to support... Chipkill? It's the IBM technology that works around bad memory by detecting single-bit errors and removing the chip that caused it from use. I'd think of this as a big hammer version of that in software. Besides, eventually you'll want to replace the DIMM that has the bad chip, and what better way then while the system is still running (as long as it's stable, of course ;) I'm just thinking out loud, so someone can correct me if I'm being loopy... - Pete - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha "process table hang"
Hmpf. Haven't seen this at all on any of the Alphas that I'm running. What exact system are you seeing this on, and what are you running when it happens? - Pete Bob McElrath wrote: > Peter Rival [[EMAIL PROTECTED]] wrote: > > You wouldn't happen to have khttpd loaded as a module, would you? I've seen > > this type of problem caused by that before... > > Nope... > > > > > - Pete > > > > Bob McElrath wrote: > > > > > I've been experiencing a particular kind of hang for many versions > > > (since 2.3.99 days, recently seen with 2.4.1, 2.4.2, and 2.4.2-ac4) on > > > the alpha architecture. The symptom is that any program that tries to > > > access the process table will hang. (ps, w, top) The hang will go away > > > by itself after ~10minutes - 1 hour or so. When it hangs I run ps and > > > see that it gets halfway through the process list and hangs. The > > > process that comes next in the list (after hang goes away) almost always > > > has nonsensical memory numbers, like multi-gigabyte SIZE. > > > > > > Linux draal.physics.wisc.edu 2.3.99-pre5 #8 Sun Apr 23 16:21:48 CDT 2000 > > > alpha unknown > > > > > > Gnu C 2.96 > > > Gnu make 3.78.1 > > > binutils 2.10.0.18 > > > util-linux 2.11a > > > modutils 2.4.5 > > > e2fsprogs 1.18 > > > PPP2.3.11 > > > Linux C Library2.2.1 > > > Dynamic linker (ldd) 2.2.1 > > > Procps 2.0.7 > > > Net-tools 1.54 > > > Kbd0.94 > > > Sh-utils 2.0 > > > Modules Loaded nfsd lockd sunrpc af_packet msdos fat pas2 sound > > > soundcore > > > > > > Has anyone else seen this? Is there a fix? > > > > > > -- Bob > > > > > > Bob McElrath ([EMAIL PROTECTED]) > > > Univ. of Wisconsin at Madison, Department of Physics > > > > > > > > >Part 1.2Type: application/pgp-signature > -- Bob > > Bob McElrath ([EMAIL PROTECTED]) > Univ. of Wisconsin at Madison, Department of Physics > > >Part 1.2Type: application/pgp-signature - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha "process table hang"
You wouldn't happen to have khttpd loaded as a module, would you? I've seen this type of problem caused by that before... - Pete Bob McElrath wrote: > I've been experiencing a particular kind of hang for many versions > (since 2.3.99 days, recently seen with 2.4.1, 2.4.2, and 2.4.2-ac4) on > the alpha architecture. The symptom is that any program that tries to > access the process table will hang. (ps, w, top) The hang will go away > by itself after ~10minutes - 1 hour or so. When it hangs I run ps and > see that it gets halfway through the process list and hangs. The > process that comes next in the list (after hang goes away) almost always > has nonsensical memory numbers, like multi-gigabyte SIZE. > > Linux draal.physics.wisc.edu 2.3.99-pre5 #8 Sun Apr 23 16:21:48 CDT 2000 > alpha unknown > > Gnu C 2.96 > Gnu make 3.78.1 > binutils 2.10.0.18 > util-linux 2.11a > modutils 2.4.5 > e2fsprogs 1.18 > PPP2.3.11 > Linux C Library2.2.1 > Dynamic linker (ldd) 2.2.1 > Procps 2.0.7 > Net-tools 1.54 > Kbd0.94 > Sh-utils 2.0 > Modules Loaded nfsd lockd sunrpc af_packet msdos fat pas2 sound > soundcore > > Has anyone else seen this? Is there a fix? > > -- Bob > > Bob McElrath ([EMAIL PROTECTED]) > Univ. of Wisconsin at Madison, Department of Physics > > >Part 1.2Type: application/pgp-signature - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha process table hang
You wouldn't happen to have khttpd loaded as a module, would you? I've seen this type of problem caused by that before... - Pete Bob McElrath wrote: I've been experiencing a particular kind of hang for many versions (since 2.3.99 days, recently seen with 2.4.1, 2.4.2, and 2.4.2-ac4) on the alpha architecture. The symptom is that any program that tries to access the process table will hang. (ps, w, top) The hang will go away by itself after ~10minutes - 1 hour or so. When it hangs I run ps and see that it gets halfway through the process list and hangs. The process that comes next in the list (after hang goes away) almost always has nonsensical memory numbers, like multi-gigabyte SIZE. Linux draal.physics.wisc.edu 2.3.99-pre5 #8 Sun Apr 23 16:21:48 CDT 2000 alpha unknown Gnu C 2.96 Gnu make 3.78.1 binutils 2.10.0.18 util-linux 2.11a modutils 2.4.5 e2fsprogs 1.18 PPP2.3.11 Linux C Library2.2.1 Dynamic linker (ldd) 2.2.1 Procps 2.0.7 Net-tools 1.54 Kbd0.94 Sh-utils 2.0 Modules Loaded nfsd lockd sunrpc af_packet msdos fat pas2 sound soundcore Has anyone else seen this? Is there a fix? -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics Part 1.2Type: application/pgp-signature - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha process table hang
Hmpf. Haven't seen this at all on any of the Alphas that I'm running. What exact system are you seeing this on, and what are you running when it happens? - Pete Bob McElrath wrote: Peter Rival [[EMAIL PROTECTED]] wrote: You wouldn't happen to have khttpd loaded as a module, would you? I've seen this type of problem caused by that before... Nope... - Pete Bob McElrath wrote: I've been experiencing a particular kind of hang for many versions (since 2.3.99 days, recently seen with 2.4.1, 2.4.2, and 2.4.2-ac4) on the alpha architecture. The symptom is that any program that tries to access the process table will hang. (ps, w, top) The hang will go away by itself after ~10minutes - 1 hour or so. When it hangs I run ps and see that it gets halfway through the process list and hangs. The process that comes next in the list (after hang goes away) almost always has nonsensical memory numbers, like multi-gigabyte SIZE. Linux draal.physics.wisc.edu 2.3.99-pre5 #8 Sun Apr 23 16:21:48 CDT 2000 alpha unknown Gnu C 2.96 Gnu make 3.78.1 binutils 2.10.0.18 util-linux 2.11a modutils 2.4.5 e2fsprogs 1.18 PPP2.3.11 Linux C Library2.2.1 Dynamic linker (ldd) 2.2.1 Procps 2.0.7 Net-tools 1.54 Kbd0.94 Sh-utils 2.0 Modules Loaded nfsd lockd sunrpc af_packet msdos fat pas2 sound soundcore Has anyone else seen this? Is there a fix? -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics Part 1.2Type: application/pgp-signature -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics Part 1.2Type: application/pgp-signature - 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_scan problem.
Doug, could you check how this patch works if you have the qla2x00 installed in an
Alpha box? I'm hoping this is part of the source of my problems, but I'm not
positive. (I'd do it, but my system is running benchmarks for the next several
days.) Thanks!
- Pete
Doug Ledford wrote:
> Ishikawa wrote:
> >
> > Hi,
> >
> > I have an "old" Nakamichi CD changer.
> > ("old" might be important consideration here. )
> >
> > Should I test the patch submitted and report what I found ?
> > (Or maybe I don't have to bother at this stage at all
> > and simply wait for the 2.5 development and debugging cycle?)
>
> It would still be helpful because this problem has to be fixed before 2.5.
> The only question is whether to fix it with a simple patch such as I just
> submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
> is how my simple patch works on your device.
>
> --
>
> Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
> Please check my web site for aic7xxx updates/answers before
> e-mailing me about problems
> -
> 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/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_scan problem.
Doug, could you check how this patch works if you have the qla2x00 installed in an
Alpha box? I'm hoping this is part of the source of my problems, but I'm not
positive. (I'd do it, but my system is running benchmarks for the next several
days.) Thanks!
- Pete
Doug Ledford wrote:
Ishikawa wrote:
Hi,
I have an "old" Nakamichi CD changer.
("old" might be important consideration here. )
Should I test the patch submitted and report what I found ?
(Or maybe I don't have to bother at this stage at all
and simply wait for the 2.5 development and debugging cycle?)
It would still be helpful because this problem has to be fixed before 2.5.
The only question is whether to fix it with a simple patch such as I just
submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
is how my simple patch works on your device.
--
Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Big Bada Boom...
Yeah, I've been bitten by this quite often. Basically, just edit arch/alpha/kernel/Makefile and remove irq_pyxis.c from the obj-y line. I'm not positive what systems require it exactly, but rawhide isn't one of them. I have a totally separate patch from Andrea that suggests (to my mind) that it is required for: GENERIC, CIA, CABRIOLET, EV164, EB66P, LX164, PC164, MIATA, RUFFIAN and SX164. Does someone want to verify that and then a quickie patch can be whipped up and sent in. - Pete Greg from Systems wrote: > 2.4.0 Kernel problem... > Alpha version only.. > > This seems to be purely a source problem... > > attached is my .config, and here is the problem: > > when using the attached .config and running a 'make dep ; make boot' I get > the following: > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Big Bada Boom...
Yeah, I've been bitten by this quite often. Basically, just edit arch/alpha/kernel/Makefile and remove irq_pyxis.c from the obj-y line. I'm not positive what systems require it exactly, but rawhide isn't one of them. I have a totally separate patch from Andrea that suggests (to my mind) that it is required for: GENERIC, CIA, CABRIOLET, EV164, EB66P, LX164, PC164, MIATA, RUFFIAN and SX164. Does someone want to verify that and then a quickie patch can be whipped up and sent in. - Pete Greg from Systems wrote: 2.4.0 Kernel problem... Alpha version only.. This seems to be purely a source problem... attached is my .config, and here is the problem: when using the attached .config and running a 'make dep ; make boot' I get the following: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: QLogicFC problems with 2.4.x?
This is just to let everyone know that, thanks to Craig Ruff, I now have qlogicfc working under 2.4.11 on my ES40 and GS80. The secret is to set CONNECTION_PREFERENCE to P2P_ONLY instead of LOOP_ONLY, and to build it in to the kernel instead of as a module. My problem now is that the GS80 oopses when I try to mke2fs the second stripe set on the HSG80. This _only_ happens on the second mke2fs, not the first. Screen dump is as follows: #mke2fs /dev/sde2 Writing inode tables: done Writing superblocks and filesystem accounting information: pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables Unable to handle kernel paging request at virtual address 003ffc1a I've inlined the ksymoops output below. I still haven't gotten the qla2x00 driver working... kinda strange... I'll also be trying Matthew Jacob's driver as soon as I get the chance. Thanks for all the suggestions everyone! - Pete ksymoops 0.7c on alpha 2.4.0-test11. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test11/ (default) -m /usr/tmp/System.map (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Unable to handle kernel paging request at virtual address 003ffc1a CPU 0 swapper(0): Oops 1 pc = [] ra = [] ps = 0007 Using defaults from ksymoops -t elf64-alpha -a alpha Warning (Oops_read): Code line not seen, dumping what data is available >>PC; fc81ca40<= gp = fcab9460 sp = fca1bd98 Code: fc0043f209a1 fc0042220642 fc00e428 fc002fe0 fc0047ff041f fc002fe0 fc00b7e2 fc0040603403 Code; fc81ca40 <_PC>: Code; fc81ca40 0: a1 09 f2 43 cmplt zero,a2,t0 Code; fc81ca44 4: 00 fc ff ff bgt zero,f008 <_PC+0xf008> fc81ba48 Code; fc81ca48 8: 42 06 22 42 s8addq a1,t1,t1 Code; fc81ca4c c: 00 fc ff ff bgt zero,f010 <_PC+0xf010> fc81ba50 Code; fc81ca50 10: 08 00 20 e4 beq t0,34 <_PC+0x34> fc81ca74 Code; fc81ca54 14: 00 fc ff ff bgt zero,f018 <_PC+0xf018> fc81ba58 Code; fc81ca58 18: 00 00 e0 2f unop Code; fc81ca5c 1c: 00 fc ff ff bgt zero,f020 <_PC+0xf020> fc81ba60 Code; fc81ca60 20: 1f 04 ff 47 nop Code; fc81ca64 24: 00 fc ff ff bgt zero,f028 <_PC+0xf028> fc81ba68 Code; fc81ca68 28: 00 00 e0 2f unop Code; fc81ca6c 2c: 00 fc ff ff bgt zero,f030 <_PC+0xf030> fc81ba70 Code; fc81ca70 30: 00 00 e2 b7 stq zero,0(t1) Code; fc81ca74 34: 00 fc ff ff bgt zero,f038 <_PC+0xf038> fc81ba78 Code; fc81ca78 38: 03 34 60 40 addq t2,0x1,t2 Code; fc81ca7c 3c: 00 fc ff ff bgt zero,f040 <_PC+0xf040> fc81ba80 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! 2 warnings issued. Results may not be reliable. Peter Rival wrote: > Hi, > > I was just lent a QLogic ISP2200 FC adapter and have been having a > bear of a time trying to get it to work on my Alpha ES40 and GS80. > I've tried both the qlogicfc (with standard kernel) and qla2x00 (from > QLogic and Compaq) driver both built-in and as modules but neither of > them are working. Has anyone had success with later (I'm using > 2.4.0-test11) 2.4 kernels and the QLogic FC adapter? I'm currently > plugged into a Brocade switch (Plaides I, I believe) which is also > attached to two pair of HSG80 FC RAID controllers. AFAIK, the 2200 > is supposed to work with an FC fabric, so this should work, right? > Can anyone offer any assistance? Thanks! > > - Pete > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: QLogicFC problems with 2.4.x?
This is just to let everyone know that, thanks to Craig Ruff, I now have qlogicfc working under 2.4.11 on my ES40 and GS80. The secret is to set CONNECTION_PREFERENCE to P2P_ONLY instead of LOOP_ONLY, and to build it in to the kernel instead of as a module. My problem now is that the GS80 oopses when I try to mke2fs the second stripe set on the HSG80. This _only_ happens on the second mke2fs, not the first. Screen dump is as follows: #mke2fs /dev/sde2 Writing inode tables: done Writing superblocks and filesystem accounting information: pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables pci_map_sg failed: could not allocate dma page tables Unable to handle kernel paging request at virtual address 003ffc1a I've inlined the ksymoops output below. I still haven't gotten the qla2x00 driver working... kinda strange... I'll also be trying Matthew Jacob's driver as soon as I get the chance. Thanks for all the suggestions everyone! - Pete ksymoops 0.7c on alpha 2.4.0-test11. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test11/ (default) -m /usr/tmp/System.map (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Unable to handle kernel paging request at virtual address 003ffc1a CPU 0 swapper(0): Oops 1 pc = [fc81ca40] ra = [fc81d4a4] ps = 0007 Using defaults from ksymoops -t elf64-alpha -a alpha Warning (Oops_read): Code line not seen, dumping what data is available PC; fc81ca40 iommu_arena_free+20/40 = gp = fcab9460 sp = fca1bd98 Code: fc0043f209a1 fc0042220642 fc00e428 fc002fe0 fc0047ff041f fc002fe0 fc00b7e2 fc0040603403 Code; fc81ca40 iommu_arena_free+20/40 _PC: Code; fc81ca40 iommu_arena_free+20/40 0: a1 09 f2 43 cmplt zero,a2,t0 Code; fc81ca44 iommu_arena_free+24/40 4: 00 fc ff ff bgt zero,f008 _PC+0xf008 fc81ba48 smp_call_function+108/140 Code; fc81ca48 iommu_arena_free+28/40 8: 42 06 22 42 s8addq a1,t1,t1 Code; fc81ca4c iommu_arena_free+2c/40 c: 00 fc ff ff bgt zero,f010 _PC+0xf010 fc81ba50 smp_call_function+110/140 Code; fc81ca50 iommu_arena_free+30/40 10: 08 00 20 e4 beq t0,34 _PC+0x34 fc81ca74 pci_map_single+14/1a0 Code; fc81ca54 iommu_arena_free+34/40 14: 00 fc ff ff bgt zero,f018 _PC+0xf018 fc81ba58 smp_call_function+118/140 Code; fc81ca58 iommu_arena_free+38/40 18: 00 00 e0 2f unop Code; fc81ca5c iommu_arena_free+3c/40 1c: 00 fc ff ff bgt zero,f020 _PC+0xf020 fc81ba60 smp_call_function+120/140 Code; fc81ca60 pci_map_single+0/1a0 20: 1f 04 ff 47 nop Code; fc81ca64 pci_map_single+4/1a0 24: 00 fc ff ff bgt zero,f028 _PC+0xf028 fc81ba68 smp_call_function+128/140 Code; fc81ca68 pci_map_single+8/1a0 28: 00 00 e0 2f unop Code; fc81ca6c pci_map_single+c/1a0 2c: 00 fc ff ff bgt zero,f030 _PC+0xf030 fc81ba70 smp_call_function+130/140 Code; fc81ca70 pci_map_single+10/1a0 30: 00 00 e2 b7 stq zero,0(t1) Code; fc81ca74 pci_map_single+14/1a0 34: 00 fc ff ff bgt zero,f038 _PC+0xf038 fc81ba78 smp_call_function+138/140 Code; fc81ca78 pci_map_single+18/1a0 38: 03 34 60 40 addq t2,0x1,t2 Code; fc81ca7c pci_map_single+1c/1a0 3c: 00 fc ff ff bgt zero,f040 _PC+0xf040 fc81ba80 ipi_imb+0/20 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! 2 warnings issued. Results may not be reliable. Peter Rival wrote: Hi, I was just lent a QLogic ISP2200 FC adapter and have been having a bear of a time trying to get it to work on my Alpha ES40 and GS80. I've tried both the qlogicfc (with standard kernel) and qla2x00 (from QLogic and Compaq) driver both built-in and as modules but neither of them are working. Has anyone had success with later (I'm using 2.4.0-test11) 2.4 kernels and the QLogic FC adapter? I'm currently plugged into a Brocade switch (Plaides I, I believe) which is also attached to two pair of HSG80 FC RAID controllers. AFAIK, the 2200 is supposed to work with an FC fabric, so this should work, right? Can anyone offer any
QLogicFC problems with 2.4.x?
Hi, I was just lent a QLogic ISP2200 FC adapter and have been having a bear of a time trying to get it to work on my Alpha ES40 and GS80. I've tried both the qlogicfc (with standard kernel) and qla2x00 (from QLogic and Compaq) driver both built-in and as modules but neither of them are working. Has anyone had success with later (I'm using 2.4.0-test11) 2.4 kernels and the QLogic FC adapter? I'm currently plugged into a Brocade switch (Plaides I, I believe) which is also attached to two pair of HSG80 FC RAID controllers. AFAIK, the 2200 is supposed to work with an FC fabric, so this should work, right? Can anyone offer any assistance? Thanks! - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
QLogicFC problems with 2.4.x?
Hi, I was just lent a QLogic ISP2200 FC adapter and have been having a bear of a time trying to get it to work on my Alpha ES40 and GS80. I've tried both the qlogicfc (with standard kernel) and qla2x00 (from QLogic and Compaq) driver both built-in and as modules but neither of them are working. Has anyone had success with later (I'm using 2.4.0-test11) 2.4 kernels and the QLogic FC adapter? I'm currently plugged into a Brocade switch (Plaides I, I believe) which is also attached to two pair of HSG80 FC RAID controllers. AFAIK, the 2200 is supposed to work with an FC fabric, so this should work, right? Can anyone offer any assistance? Thanks! - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Hi Phil, Phillip Ezolt wrote: > Hi All, > > Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal >WorkStation 600au). > > When starting up, we get a machine check after initialing the qlogic SCSI code. > > Using the Alpha kgdb, we figured out that the code is dying in scsi_wait_request(). Wow, I'm impressed! I didn't realize that kgdb worked on Alpha...Were you using the remote kgdb? (You can answer me offline to save bandwidth.) This would be a _huge_ help in trying to figure out why my Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I stole from Jay and have been hacking on. Speaking of that system, it has two QLogic adapters in it (both 1040Bs, like the Miata), and they are working just fine under 2.4.0-test11 (obviously, without my changes ;). It looks like it's probably the platform code that's busted. I can't remember...are those Pyxis or CIA? Anyway, could this have something to do with the PCI & PCI bridge work that Richard and Ivan just submitted? - Pete > > Here's the backtrace: > > scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, > buffer=0x100, bufflen=2, timeout=17891584, retries=6144) > at /usr/src/linux/include/asm/atomic.h:85 > (gdb) where > #0 scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, > buffer=0x100, bufflen=2, timeout=17891584, retries=6144) > at /usr/src/linux/include/asm/atomic.h:85 > #1 0xfc4107f0 in scan_scsis_single (channel=0, dev=41080, lun=0, > max_dev_lun=0xfc1efa30, sparse_lun=0xfc1efa34, > SDpnt2=0xfc1efa38, shpnt=0xfc5ff800, > scsi_result=0xfc1ef930 "\001") at scsi_scan.c:516 > #2 0xfc410548 in scan_scsis (shpnt=0xfc5ff800, hardcoded=1, > hchannel=0, hid=0, hlun=0) at scsi_scan.c:403 > #3 0xfc404f58 in scsi_register_host (tpnt=0xfc58fb80) > at scsi.c:1904 > #4 0xfc4dac50 in init_this_scsi_driver () > #5 0xfc4c2bec in do_initcalls () > #6 0xfc4c2c6c in do_basic_setup () > #7 0xfc310078 in init (unused=0x0) at init/main.c:775 > > > Note: On the working kernels, the two controllers are 0x800 apart, but > on the broken kernels, they are only 0x400. Could the overlap > cause problems? > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Hi Phil, Phillip Ezolt wrote: Hi All, Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal WorkStation 600au). When starting up, we get a machine check after initialing the qlogic SCSI code. Using the Alpha kgdb, we figured out that the code is dying in scsi_wait_request(). Wow, I'm impressed! I didn't realize that kgdb worked on Alpha...Were you using the remote kgdb? (You can answer me offline to save bandwidth.) This would be a _huge_ help in trying to figure out why my Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I stole from Jay and have been hacking on. Speaking of that system, it has two QLogic adapters in it (both 1040Bs, like the Miata), and they are working just fine under 2.4.0-test11 (obviously, without my changes ;). It looks like it's probably the platform code that's busted. I can't remember...are those Pyxis or CIA? Anyway, could this have something to do with the PCI PCI bridge work that Richard and Ivan just submitted? - Pete Here's the backtrace: scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, buffer=0x100, bufflen=2, timeout=17891584, retries=6144) at /usr/src/linux/include/asm/atomic.h:85 (gdb) where #0 scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, buffer=0x100, bufflen=2, timeout=17891584, retries=6144) at /usr/src/linux/include/asm/atomic.h:85 #1 0xfc4107f0 in scan_scsis_single (channel=0, dev=41080, lun=0, max_dev_lun=0xfc1efa30, sparse_lun=0xfc1efa34, SDpnt2=0xfc1efa38, shpnt=0xfc5ff800, scsi_result=0xfc1ef930 "\001") at scsi_scan.c:516 #2 0xfc410548 in scan_scsis (shpnt=0xfc5ff800, hardcoded=1, hchannel=0, hid=0, hlun=0) at scsi_scan.c:403 #3 0xfc404f58 in scsi_register_host (tpnt=0xfc58fb80) at scsi.c:1904 #4 0xfc4dac50 in init_this_scsi_driver () #5 0xfc4c2bec in do_initcalls () #6 0xfc4c2c6c in do_basic_setup () #7 0xfc310078 in init (unused=0x0) at init/main.c:775 Note: On the working kernels, the two controllers are 0x800 apart, but on the broken kernels, they are only 0x400. Could the overlap cause problems? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SparcLinux on Sun E10000
bert hubert wrote: > On Wed, Sep 27, 2000 at 05:28:49PM +1100, Anton Blanchard wrote: > > > Memory: 23824288k available (1352k kernel code, 240k data, 72k init) >[f800,0012ffc9a000] > > This must be some kind of record. > Sorry...check the post I made a few hours ago. Unless I count my digits wrong, that's ~24GB of memory. The GS320 we booted here a while ago has 256GB. Either way, tho', that's a _lot_ of memory! - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux boots on Wildfire^WGS320!
Hi all, Well, I'm finally getting around to sending out this announcement. As can be seen on www.alphanews.net, we've managed to boot Linux on an AlphaServer GS320. The only caveats are that one of the CPUs was out of the system at the time (hence 31 CPUs, not 32), and that we haven't yet finished the DISCONTIGMEM support for Alpha (hence the 480GB of memory, instead of the real 256GB). Needless to say, things like kernel builds run _really_ fast. Heck, I could put all of my workstation (several times over, in fact) into RAM on this thing! I'm gonna have to put a graphics head on this and see how Quake runs... ;) - Pete P00>>>b dkb100 -fi 3/vmlinux.24t7p7-frival.gz -fl "root=/dev/sdc3 console=ttyS0" (boot dkb100.1.0.6.3 -file 3/vmlinux.24t7p7-frival.gz -flags root=/dev/sdc3 cons ole=ttyS0) block 0 of dkb100.1.0.6.3 is a valid boot block reading 162 blocks from dkb100.1.0.6.3 bootstrap code read in base = 4de000, image_start = 0, image_bytes = 14400 initializing HWRPB at 2000 initializing page table at 7fff7 initializing machine state setting affinity to the primary CPU jumping to bootstrap code aboot: Linux/Alpha SRM bootloader version 0.7 aboot: switching to OSF/1 PALcode version 1.75 aboot: booting from device 'SCSI 3 6 0 1 100 0 0' aboot: valid disklabel found: 4 partitions. aboot: loading compressed vmlinux.24t7p7-frival.gz... aboot: zero-filling 1191068 bytes at fca8f0b4 aboot: starting kernel vmlinux.24t7p7-frival.gz with arguments root=/dev/sdc3 co nsole=ttyS0 Linux version 2.4.0-test7 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 SMP Wed Aug 23 17:18:27 EDT 2000 Booting on Wildfire using machine vector WILDFIRE from SRM Command line: root=/dev/sdc3 console=ttyS0 memcluster 0, usage 1, start0, end 623 memcluster 1, usage 0, start 623, end 4194231 memcluster 2, usage 1, start 4194231, end 4194304 memcluster 3, usage 0, start 8388608, end 12582832 memcluster 4, usage 1, start 12582832, end 12582912 memcluster 5, usage 0, start 16777216, end 20971440 memcluster 6, usage 1, start 20971440, end 20971520 memcluster 7, usage 0, start 25165824, end 29360048 memcluster 8, usage 1, start 29360048, end 29360128 memcluster 9, usage 0, start 33554432, end 37748656 memcluster 10, usage 1, start 37748656, end 37748736 memcluster 11, usage 0, start 41943040, end 46137264 memcluster 12, usage 1, start 46137264, end 46137344 memcluster 13, usage 0, start 50331648, end 54525872 memcluster 14, usage 1, start 54525872, end 54525952 memcluster 15, usage 0, start 58720256, end 62914480 memcluster 16, usage 1, start 62914480, end 62914560 freeing pages 623:1024 freeing pages 1499:4194231 freeing pages 8388608:12582832 freeing pages 16777216:20971440 freeing pages 25165824:29360048 freeing pages 33554432:37748656 freeing pages 41943040:46137264 freeing pages 50331648:54525872 freeing pages 58720256:62914480 Probed Hardware Configuration hard_qbb_mask: 0x ff soft_qbb_mask: 0x ff gp_mask:0x ff hs_mask:0x 1 iop_mask: 0x ff ior_mask: 0x pca_mask: 0x1133 cpu_mask: 0xff7f mem_mask: 0x hard_qbb_map: 0 1 2 3 4 5 6 7 soft_qbb_map: 0 1 2 3 4 5 6 7 SMP: 31 CPUs probed -- cpu_present_mask = ff7f On node 0 totalpages: 62914560 zone(0): 62914560 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sdc3 console=ttyS0 Using epoch = 1952 Calibrating delay loop... 1488.98 BogoMIPS Memory: 260537664k/503315840k available (1516k kernel code, 7887744k reserved, 5 40k data, 448k init) Dentry-cache hash table entries: 262144 (order: 9, 4194304 bytes) Buffer-cache hash table entries: 524288 (order: 9, 4194304 bytes) Page-cache hash table entries: 524288 (order: 9, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 4194304 bytes) POSIX conformance testing by UNIFIX Using heuristic of 2147483647 cycles. SMP starting up secondaries. Calibrating delay loop... 1493.17 BogoMIPS Calibrating delay loop... 1493.17 BogoMIPS Calibrating delay loop... 1493.17 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98
Linux boots on Wildfire^WGS320!
Hi all, Well, I'm finally getting around to sending out this announcement. As can be seen on www.alphanews.net, we've managed to boot Linux on an AlphaServer GS320. The only caveats are that one of the CPUs was out of the system at the time (hence 31 CPUs, not 32), and that we haven't yet finished the DISCONTIGMEM support for Alpha (hence the 480GB of memory, instead of the real 256GB). Needless to say, things like kernel builds run _really_ fast. Heck, I could put all of my workstation (several times over, in fact) into RAM on this thing! I'm gonna have to put a graphics head on this and see how Quake runs... ;) - Pete P00b dkb100 -fi 3/vmlinux.24t7p7-frival.gz -fl "root=/dev/sdc3 console=ttyS0" (boot dkb100.1.0.6.3 -file 3/vmlinux.24t7p7-frival.gz -flags root=/dev/sdc3 cons ole=ttyS0) block 0 of dkb100.1.0.6.3 is a valid boot block reading 162 blocks from dkb100.1.0.6.3 bootstrap code read in base = 4de000, image_start = 0, image_bytes = 14400 initializing HWRPB at 2000 initializing page table at 7fff7 initializing machine state setting affinity to the primary CPU jumping to bootstrap code aboot: Linux/Alpha SRM bootloader version 0.7 aboot: switching to OSF/1 PALcode version 1.75 aboot: booting from device 'SCSI 3 6 0 1 100 0 0' aboot: valid disklabel found: 4 partitions. aboot: loading compressed vmlinux.24t7p7-frival.gz... aboot: zero-filling 1191068 bytes at fca8f0b4 aboot: starting kernel vmlinux.24t7p7-frival.gz with arguments root=/dev/sdc3 co nsole=ttyS0 Linux version 2.4.0-test7 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 SMP Wed Aug 23 17:18:27 EDT 2000 Booting on Wildfire using machine vector WILDFIRE from SRM Command line: root=/dev/sdc3 console=ttyS0 memcluster 0, usage 1, start0, end 623 memcluster 1, usage 0, start 623, end 4194231 memcluster 2, usage 1, start 4194231, end 4194304 memcluster 3, usage 0, start 8388608, end 12582832 memcluster 4, usage 1, start 12582832, end 12582912 memcluster 5, usage 0, start 16777216, end 20971440 memcluster 6, usage 1, start 20971440, end 20971520 memcluster 7, usage 0, start 25165824, end 29360048 memcluster 8, usage 1, start 29360048, end 29360128 memcluster 9, usage 0, start 33554432, end 37748656 memcluster 10, usage 1, start 37748656, end 37748736 memcluster 11, usage 0, start 41943040, end 46137264 memcluster 12, usage 1, start 46137264, end 46137344 memcluster 13, usage 0, start 50331648, end 54525872 memcluster 14, usage 1, start 54525872, end 54525952 memcluster 15, usage 0, start 58720256, end 62914480 memcluster 16, usage 1, start 62914480, end 62914560 freeing pages 623:1024 freeing pages 1499:4194231 freeing pages 8388608:12582832 freeing pages 16777216:20971440 freeing pages 25165824:29360048 freeing pages 33554432:37748656 freeing pages 41943040:46137264 freeing pages 50331648:54525872 freeing pages 58720256:62914480 Probed Hardware Configuration hard_qbb_mask: 0x ff soft_qbb_mask: 0x ff gp_mask:0x ff hs_mask:0x 1 iop_mask: 0x ff ior_mask: 0x pca_mask: 0x1133 cpu_mask: 0xff7f mem_mask: 0x hard_qbb_map: 0 1 2 3 4 5 6 7 soft_qbb_map: 0 1 2 3 4 5 6 7 SMP: 31 CPUs probed -- cpu_present_mask = ff7f On node 0 totalpages: 62914560 zone(0): 62914560 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sdc3 console=ttyS0 Using epoch = 1952 Calibrating delay loop... 1488.98 BogoMIPS Memory: 260537664k/503315840k available (1516k kernel code, 7887744k reserved, 5 40k data, 448k init) Dentry-cache hash table entries: 262144 (order: 9, 4194304 bytes) Buffer-cache hash table entries: 524288 (order: 9, 4194304 bytes) Page-cache hash table entries: 524288 (order: 9, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 4194304 bytes) POSIX conformance testing by UNIFIX Using heuristic of 2147483647 cycles. SMP starting up secondaries. Calibrating delay loop... 1493.17 BogoMIPS Calibrating delay loop... 1493.17 BogoMIPS Calibrating delay loop... 1493.17 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS Calibrating delay loop... 1488.98 BogoMIPS
Re: SparcLinux on Sun E10000
bert hubert wrote: On Wed, Sep 27, 2000 at 05:28:49PM +1100, Anton Blanchard wrote: Memory: 23824288k available (1352k kernel code, 240k data, 72k init) [f800,0012ffc9a000] This must be some kind of record. Sorry...check the post I made a few hours ago. Unless I count my digits wrong, that's ~24GB of memory. The GS320 we booted here a while ago has 256GB. Either way, tho', that's a _lot_ of memory! - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Scalability Efforts
Rik van Riel wrote: > On Thu, 7 Sep 2000, Henry Worth wrote: > > > > Or is it all, whatever there may be of it, taking > > place offline? > > Most of the times I've talked about this topic it > was in person with other developers at various > conferences. > Ugh, no wonder I never see this. Guess it's time to get some trips paid for so I can stand near you guys and listen to what's going on ;) > > For the VM subsystem and the scheduler we have some > ideas to improve scalability for NUMA machines. It's > not been implemented yet, but for most of it the > design seems to be pretty ok and ready to be implemented > for 2.5. > Is any of this documented in any way? I'm the one that booted Linux on a 31 (one CPU was bad at the time) CPU 256GB GS Series Alphaserver, and NUMA has always been a favorite play-thing of mine. :) > > OTOH, some of the develish details still aren't resolved. > If there are people interested in discussing this topic, > I'll setup a mailing list for it ... > Sure, unless people really want it to stay here. Heck, I'd even sign up twice just to make sure I don't miss anything. ;) - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Scalability Efforts
Rik van Riel wrote: On Thu, 7 Sep 2000, Henry Worth wrote: snip Or is it all, whatever there may be of it, taking place offline? Most of the times I've talked about this topic it was in person with other developers at various conferences. Ugh, no wonder I never see this. Guess it's time to get some trips paid for so I can stand near you guys and listen to what's going on ;) For the VM subsystem and the scheduler we have some ideas to improve scalability for NUMA machines. It's not been implemented yet, but for most of it the design seems to be pretty ok and ready to be implemented for 2.5. Is any of this documented in any way? I'm the one that booted Linux on a 31 (one CPU was bad at the time) CPU 256GB GS Series Alphaserver, and NUMA has always been a favorite play-thing of mine. :) OTOH, some of the develish details still aren't resolved. If there are people interested in discussing this topic, I'll setup a mailing list for it ... Sure, unless people really want it to stay here. Heck, I'd even sign up twice just to make sure I don't miss anything. ;) - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Rik van Riel's VM patch
"Jeff V. Merkey" wrote: > Someone tell Rik to get his hands on a copy of AIMS-7 and start > benchmarking his VM so when the SCO Unix numbers hit the street, we've > got a rebuttal and fix dates to tell folks. > That's going to be tough - AIM as a company is out of business (just go to www.aim.com and be surprised ;). And not to get off-topic, but there are bigger problems with AIM7 tests than the VM (like the fact that they have hundreds of runnable processes at any given time which our global run queue doesn't handle well). Really - pick something like SPECWeb99...oh, wait - we already destroy the competition there... :) - Pete (still looking for a complete systemic test that's like AIM only more realistic) > > :-) > > Jeff > > Bill Huey wrote: > > > > John, > > > > > Hi, this is just a short no-statistics testimony that Rik's VM patch > > > to test8-pre1 seems much improved over test7. I have a UP P200 with 40Mb, > > > and previously running KDE2 + mozilla was totally unusable. > > > > > With the patch, things run much more smoothly. Interactive feel seems > > > better, and I don't have "swapping holidays" any more. > > > > > Heavily stressing it by g++ is better as well... > > > > > > just a data point, > > > john > > > > Yes, it kicks butt and it finally (just about) removes the final > > Linux kernel showstopper for recent kernels. ;-) > > > > I did a GNOME + KDE2 + c++ compile since I've been doing port work > > and I have similar experiences. > > > > bill > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
