INFO-VAX Wed, 15 Oct 2008 Volume 2008 : Issue 556 Contents: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: DS10 front access storage cage (3X-BA10B-AA) Re: Status of Intel's Common System Interconnect ? Re: Status of Intel's Common System Interconnect ? Re: Status of Intel's Common System Interconnect ? ---------------------------------------------------------------------- Date: Tue, 14 Oct 2008 19:13:42 -0700 (PDT) From: PR Subject: Bypass mount/system request at boot time? Message-ID: <0f71d7a7-45cf-4f1a-8caa-24a40e8a77a2@b31g2000prf.googlegroups.com> I have a remote client that has somehow gotten himself into a mess, and I'm not sure how to get them out of it remotely. They hired a consultant to come in an "work on the network." This - ah - "brilliant person" apparently convinced them he just had to reboot the 2660. He booted the 2660 system with a Linux DVD and somehow or another, managed to format the second drive (used for data storage) with Linux. How is beyond me... Anyway, I'm a good 500 miles away from this server physically, and there is a mount/system command in the systartup_vms.com file to mount this noe Linux formatted disk. Which obviously won't mount. The system boot stalls at this mount request. I think I might be able to put an /ASSIST qualifier in there and cancel the mount, but I have to get past the mount request to do that. :) Is there any easy way around this? Will just pulling the drive enable it to bypass? I'm overnighting a freshly formatted drive that will mount, but if I can get this production box up tonight, it would be a nice thing. Sneaky tricks invited. :) -Paul ------------------------------ Date: Tue, 14 Oct 2008 21:26:44 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: Bypass mount/system request at boot time? Message-ID: <08101421264425_2020049E@antinode.info> From: PR > Is there any easy way around this? Will just pulling the drive enable > it to bypass? If the device does not exist, the MOUNT should fail quickly and easily: ALP $ mount /system dkc0: fred %MOUNT-F-NOSUCHDEV, no such device available ALP $ I'd try pulling the drive. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 14 Oct 2008 22:49:14 -0400 From: JF Mezei Subject: Re: Bypass mount/system request at boot time? Message-ID: <48f55b6d$0$12403$c3e8da3@news.astraweb.com> PR wrote: > Anyway, I'm a good 500 miles away from this server physically, and > there is a mount/system command in the systartup_vms.com file to mount > this noe Linux formatted disk. Which obviously won't mount. Using VAX semanics: BOOT/1 SYSBOOT> SET STARTUP_P1 = "MIN" SYSBOOT> CONTINUE You can then login and edit the systartup_vms.com file and comment out the mount command, then go into sysman, set STARTUP_P1 back to nothing and reboot. ------------------------------ Date: Wed, 15 Oct 2008 02:54:19 GMT From: John Santos Subject: Re: Bypass mount/system request at boot time? Message-ID: Steven M. Schweda wrote: > From: PR > >>Is there any easy way around this? Will just pulling the drive enable >>it to bypass? > > > If the device does not exist, the MOUNT should fail quickly and > easily: > > ALP $ mount /system dkc0: fred > %MOUNT-F-NOSUCHDEV, no such device available > ALP $ > > I'd try pulling the drive. > ... and put a "$ set noon" at the beginning of systartup_vms.com :-) Otherwise, the startup will abort on the fatal "no such device error", and may leave the system up but inaccessible. I tried mounting a non-existent disk with both /assist and /noassist on Alpha VMS 8.3, and in both cases for the "%MOUNT-F-NOSUCHDEV" error, so I agree pulling the drive should make it get past this point, whatever the details of the mount command. With the disk present but unmountable, you are in this Catch-22: the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet and logins aren't enabled yet, so you can't log in to reply to the mount request. You should add /noassist to the mounts in systartup_vms.com, or stick them in a batch job that doesn't get executed until after logins are enabled and the rest of the system is up. (But you probably need the disks mounted to start the application, so I would go with mount/noassist. Then at least you can log in and fix things if a disk goes south.) HTH. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Tue, 14 Oct 2008 20:51:04 -0700 (PDT) From: PR Subject: Re: Bypass mount/system request at boot time? Message-ID: On Oct 14, 9:26=A0pm, s...@antinode.info (Steven M. Schweda) wrote: > From: PR > > > Is there any easy way around this? Will just pulling the drive enable > > it to bypass? > > =A0 =A0If the device does not exist, the MOUNT should fail quickly and > easily: > > ALP $ mount /system dkc0: fred > %MOUNT-F-NOSUCHDEV, no such device available > ALP $ > > =A0 =A0I'd try pulling the drive. > > ------------------------------------------------------------------------ > > =A0 =A0Steven M. Schweda =A0 =A0 =A0 =A0 =A0 =A0 =A0 sms@antinode-info > =A0 =A0382 South Warwick Street =A0 =A0 =A0 =A0(+1) 651-699-9818 > =A0 =A0Saint Paul =A0MN =A055105-2547 Thanks guys - pulling the drive got past the issue, and allowed me to bring the system up remotely from the MP. I edited the systartup_vms.com file as suggested, and all is now - sort of well. The disk is reinitialized and I copied the data back onto it from the production volume. Oh, for that to make sense you would need to know that this particular volume is a volume I initialize and copy all the data from production to at 6pm each day. Then I mount the thing with /NOWRITE so it is available as a read-only reference during the day, and run the tape backups off the copied data. Cheap way to keep the data consistant. I just copied todays data back onto the disk. Amazing isn't it that someone would think that a disk mounted /NOWRITE must be broken and needs to be fixed under Linux? (*sigh*) Anyone that responded and wants a six-pack of their favorite brew- send me your address via the e-mail address above. Thanks! -Paul P.S. The incompetent boob who caused this problem is, I understand, banned from ever setting foot in the site again. ------------------------------ Date: Wed, 15 Oct 2008 05:30:16 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Bypass mount/system request at boot time? Message-ID: In article , John Santos writes: > With the disk present but unmountable, you are in this Catch-22: > the normal default for MOUNT is /ASSIST, but OPCOM isn't running yet > and logins aren't enabled yet, so you can't log in to reply to the > mount request. You should add /noassist to the mounts in > systartup_vms.com, or stick them in a batch job that doesn't get > executed until after logins are enabled and the rest of the system > is up. (But you probably need the disks mounted to start the > application, so I would go with mount/noassist. Then at least you > can log in and fix things if a disk goes south.) I agree! MOUNT/NOASSIST in the startup, especially if you expect things to come up automatically out of the box after, say, an emergency reboot, power failure etc. ------------------------------ Date: Tue, 14 Oct 2008 15:37:03 -0700 (PDT) From: Len Whitwer Subject: Re: DS10 front access storage cage (3X-BA10B-AA) Message-ID: <187b3fe1-f541-487e-bc6e-c8b39020ef12@t18g2000prt.googlegroups.com> On Oct 14, 8:53=A0am, "David Turner, islandco.com" wrote: > Really? > Where? > I have been looking for these and will willingly pay that price > How many do you have available? =A0I know HP doesn't have them > > -- > David B Turner > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Island Computers US Corp > PO Box 86 > Tybee GA 31328 > > Toll Free: 1-877 636 4332 x201, Mobile x251 > Email: dtur...@islandco.com > International & Local: (001)- 404-806-7749 > Fax: 912 786 8505 > Web:www.islandco.com > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D"Len Whitwer= " wrote in message > > news:7e10ce8b-831e-477e-a7e0-99fe42922efc@s9g2000prm.googlegroups.com... > On Oct 11, 12:19 am, The Spriteman wrote: > > > i have a DS10 with internal Storage cage, but now i am searching for a > > front > > acces storage cage, > > > does anywhone here know what the best way is to find one? whithout payi= ng > > the full price. > > > i live in Amsterdam (Netherlands) > > > With regards, > > > Robin > > robinschip at hotmail dot com > > Hi Robin: > > We can get you the DS10 front access cage (3X-BA10B-AA) for $395.00 > Please let me know if I can help. > > Regards, > > -Len Whitwer > Puget Sound Data Systems, Inc. > 19501 144th Ave. NE Suite D-100 > Woodinville, WA =A098072 > e-mail =A0 =A0mailto:l...@psds.com > Internet:http://www.psds.com > Toll Free: (866)857-0710 > Tel: (425) 488-0710 > Fax: (425) 488-6414 > AOL IM: =A0lenPSDS Robin / David Yes!!! I have one in stock and can get you 4 more if you need that many!!! Please call me directly. Len Whitwer -Len Whitwer Puget Sound Data Systems, Inc. 19501 144th Ave. NE Suite D-100 Woodinville, WA 98072 e-mail mailto:len@psds.com Internet: http://www.psds.com Toll Free: (866)857-0710 Tel: (425) 488-0710 Fax: (425) 488-6414 AOL IM: lenPSDS ------------------------------ Date: Tue, 14 Oct 2008 15:22:16 -0700 (PDT) From: already5chosen@yahoo.com Subject: Re: Status of Intel's Common System Interconnect ? Message-ID: <7738bd03-562b-46c9-bb3e-366d8d46f003@f37g2000pri.googlegroups.com> On Oct 14, 1:16 am, johnwalla...@yahoo.co.uk wrote: > On Oct 13, 6:52 pm, JF Mezei wrote: > > > Will CSI really catch on? That may depend on whether it works right, > and whether it adds value as well as cost (if it *saves* cost, so much > the better). Actually I'm not as confident as you are, but the chances > of success are high. Intel do have market failures from time to time, > even in the x86 world, e.g. their in-house graphics have traditionally > been laughable. As for CSI enabling scalability to bigger systems: you > can already get a 32core 256GB Proliant based on Opteron, and even the > Xeon one already does 16 cores and 256GB. Do many sensible people > really want/need more than that? Some do, but... > Now HP has 24 cores Xeon-based gear. http://h10010.www1.hp.com/wwpc/us/en/en/WF25a/15351-15351-3328412-241644-3328422-3454575.html ------------------------------ Date: Tue, 14 Oct 2008 15:33:15 -0700 (PDT) From: already5chosen@yahoo.com Subject: Re: Status of Intel's Common System Interconnect ? Message-ID: <65e43895-20d4-4775-b4a0-f85d74dccf16@s9g2000prg.googlegroups.com> On Oct 13, 8:59 am, johnwalla...@yahoo.co.uk wrote: > On Oct 13, 5:30 am, JF Mezei wrote: > > > > > IanMiller wrote: > > > I leave as an exercise to the reader to search hp.com for quickpath > > > and Nehalem and tukwila. > > > I searched Tukwila quickpath. It gave me 9 results. The most likely > > document (a roadmap) was a neat Intel marketing garbage devoid of > > specific information. > > > You have obvioulsy way overestimated my capabilities if you thought I > > could easily find the results from an HP.COM search. > > > > According to the VMS public roadmap VMS V8.4 will run on Tukwila > > > Woopty doo.VMS roadmap is not a document where I would expect details on > > HP's hardware and whether HP's own use of Tukwila will also involve > > Quickpath or if it will have some HP proprietary chipset as I had been > > lead to believe before. > > This week's name has been Quickpath for a while now but CSI is > shorter. > > I'm not 100% sure I'm up to date either, but if I recall correctly, > CSI-based systems require Nehalem (x86-64) or Tukwila (IA64) chips. > And if I recall correctly from coverage of Intel Developer Forum from > August this year, both of them are late by months or even a year or > more. Nehalem was then said to be shipping in Q4 2008, and Tukwila in > early 2009; this may have changed, correction welcome. > > If those timescales are accurate, they presumably mean that Those In > The Know already have access to early chips, boards, and are maybe > even playing with systems, but nobody will really know when they'll > hit the market for real, and any pre-release information which is > floating around (be it HP or anyone else) will likely either be > covered by NDA and subject to change, or be content-free. Examples to > the contrary most welcome. > > I don't recall seeing any worthwhile pre-publicity for *systems* based > around either x86 or IA64 variants of CSI. > > Realistically, what does CSI buy anyone anyway that HyperTransport > hasn't offered for years (and before that there was its close relative > the EV7 bus...). Access to nicely-interconnectable chips from Intel as > well as different and electronically incompatible chips from AMD, I > suppose? > > One other thing I imagine CSI will do *if* it succeeds is make life > even harder for the relatively high-cost low-return IA64-specific > sections of Intel and HP; why continue to duplicate two sets of > engineering effort, one for x86-64 and one for electronically- > compatible near-identical kit with IA64? When the consolidation does > happen, maybe we'll eventually see a CSI-based Proliant-class system > and there'll be a second chance for IA64 to have a go in the Proliant- > class market (the first attempt was in 2003), without the IA64- > specifics making those systems cost a relative fortune to design and > build as they did back then. Then what happens with entry-level VMS > systems? > > Incidentally, speaking of costs of Itanium, elsewhere I've recently > seen it written that Itanium has brought down the cost of high quality > servers. I'm not sure about that myself. For most purposes an entry or > mid-range Itanium (the "volume market" ones) offers no features I can > see that a suitable Proliant hasn't offered for years, with Proliants > at a very realistic price (just ask the many people whose businesses > depend on them). Except Proliants don't do VMS, you need IA64 if you > want to buy a VMS box today. > > Equally, other than the CPU cost, there's been no need for any huge > difference in the bill of materials cost between an Alpha and an x86 > box since the days of the PWS family (or before that, the AlphaStation > 400 and its PC equivalent whose name I forget). Any difference in the > price these technically-similar boxes sold at was down to things other > than the cost to manufacture (ie it's a political decision), and thus > any difference in today's cost of a VMS box vs the cost a few years > ago is also a political not technical effect, not necessarily to do > with the box having "Itanium Inside" rather than "Alpha Instead", more > to do with things going on in the market in general. Maybe CSI will > change that too, but when EV6 had the same interconnect as AMD64 > Hammer, did it help EV6 conquer the world, or not? EV7 and LDT/ > Hypertransport? Soon, Itanium and CSI? > Nitpick: it's K7=Athlon (32-bit predecessor of Hammer) that had EV6- compatible external interface. Hammer is built around Hypertransport 2.x which is neither related nor similar to EV7 interconnects. The two are different at all layers, from physical, to packets, to cache-coherence protocol (EV7 cc is directory-based while Hammer uses broadcasting that delivers better small-system performance at cost of less than stellar scalability). ------------------------------ Date: Tue, 14 Oct 2008 15:48:46 -0700 (PDT) From: already5chosen@yahoo.com Subject: Re: Status of Intel's Common System Interconnect ? Message-ID: <07f77733-9869-4f1c-a64d-aae1fca7154d@k36g2000pri.googlegroups.com> On Oct 13, 7:52 pm, JF Mezei wrote: > johnwalla...@yahoo.co.uk wrote: > > I'm not 100% sure I'm up to date either, but if I recall correctly, > > CSI-based systems require Nehalem (x86-64) or Tukwila (IA64) chips. > > The question is whether Tukwila requires CSI or whether HP can have have > its own proprietary chipset. As I recall, HP has had its own chipset for > a while. (then again, if they shipped all their chip designers to Intel, > perhaps they don't have that capability anymore). > You should realize that QPI is the only way in which Tukwila could talk to the outside world. The GTL+ demultiplexed double pumped 128b-wide etc etc McKinley bus gone. Completely gone. So in theory HP doesn't have to connect between Tukwilas directly. They doesn't even have to connect Tukwila's integrated memory controller with actual DIMMs (although not doing it would be extremely stupid) . In theory they can build 4-way Tukwila-based system with topology similar to current 4-way Xeon systems where all CPUs and all memory channels are connected to the same huge chip called memory controller hub (MCH). Stupid but possible. However even in theory the MCH has to be connected through QPI. ------------------------------ End of INFO-VAX 2008.556 ************************