Re: Kernel Compilation Failure with gcc 3.4.6
Let me revise that a bit. There are three changes that need to be made.
--- linux-2.4.33.3/drivers/s390/misc/chandev.c 2006-08-31
13:03:20.0 -0400
+++ linux-2.4.33.3/drivers/s390/misc/chandev.c 2006-09-11
20:50:00.0 -0400
@@ -326,7 +326,7 @@
#define chandev_interrupt_check() \
if(in_interrupt())\
- printk(KERN_WARNING __FUNCTION__ " called under interrupt this
shouldn't happen\n")
+ printk(KERN_WARNING " %s called under interrupt this shouldn't
happen\n", __FUNCTION__)
#define for_each(variable,head) \
@@ -541,7 +541,7 @@
case chandev_msck:
argc+=3;
break;
- default:
+ default:;
}
if(have_tag[tagidx]==FALSE)
argc++;
@@ -1494,7 +1494,7 @@
}
sprintf(destnamebuff,"%s%d",basename,idx);
return(destnamebuff);
- next_idx:
+ next_idx:;
}
printk("chandev_build_device_name was
usable to build a unique name for %s\n",basename);
return(NULL);
Signed-off-by: Mark Post <[EMAIL PROTECTED]>
Mark Post
-Original Message-
From: Post, Mark K
Sent: Monday, September 11, 2006 12:45 PM
To: 'Linux on 390 Port'; '[EMAIL PROTECTED]'
Subject: RE: Kernel Compilation Failure with gcc 3.4.6
Heiko,
Thanks for your reply. Installing and using two separate versions of
gcc on the same system may be a semi-reasonable requirement for a
distribution maintainer such as myself. It's a very unreasonable
requirement for a distribution user, even a Slackware or Slack/390 one.
Further investigation has revealed something fascinating (to me anyway).
Just for the sake of completeness, I took all the developerWorks
patches, and applied them to a 2.4.21 kernel. The errors I'm seeing
about inlining did _not_ show up during the compile. So, I compared the
driver/s390/block directories between that and the 2.4.33.2 source
trees, and only a few minor, unrelated, differences were seen. Very
odd.
One error that was consistent, however, was later on (that I didn't see
at first, because the compile stopped at dasd_3990_erp.c). I think
someone needs to apply this patch:
--- linux-2.4.33.2/drivers/s390/misc/chandev.c. 2006-09-10
23:53:31.0 -0400
+++ linux-2.4.33.2/drivers/s390/misc/chandev.c 2006-09-11
01:19:08.0 -0400
@@ -326,7 +326,7 @@
#define chandev_interrupt_check() \
if(in_interrupt())\
- printk(KERN_WARNING __FUNCTION__ " called under interrupt this
shouldn't happen\n")
+ printk(KERN_WARNING " %s called under interrupt this shouldn't
happen\n", __FUNCTION__)
#define for_each(variable,head) \
Signed-off-by: Mark Post <[EMAIL PROTECTED]>
Mark Post
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Two More SHARE 107 Presentations
I've added two more presentations from SHARE 107 to the web site: 9127Mark Post VM for MVS Systems Programmers - Part 1 9128Martha McConaghyVM for MVS Systems Programmers - Part 2 As before, you can find them at http://linuxvm.org/Present/#share107 Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bacula question;
Yes, that did the trick. I changed the setting on my NFS server; "retrieve(wait)" processing attribute so the server waits for the recall to finish before it sends the response back to the client. Thanks! -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Saturday, September 09, 2006 6:57 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Bacula question; Make sure you specify on the z/OS NFS server that the server providing the filesystem is to wait synchronously for recalls to complete before returning. There is no timer in Bacula that measures that response if the server does not return a "wait" message; you're seeing the server respond with a "not available, wait a few" message that the NFS client doesn't understand. Bacula retries when it gets that message, and eventually gives up. See the z/OS NFS feature manual for the parm to specify synchronous response (don't have manuals here). David Boyes Sine Nomine Associates -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: FCP over ECKD performance advantage - why?
On Monday, 09/11/2006 at 03:02 AST, Rick Troth <[EMAIL PROTECTED]> wrote: > The point gets lost every time Alan and I butt heads on this: We have matching calouses. :-) > I should have re-iterated "tracks and records" (out of band), > which is obviously useful IFF the applications have that level > of access, but which are NOT USED by applications on CMS, Linux, > or most other operating systems (going beyond zSeries here). > So apps don't have access, so is rendered useless if not > intrinsically so. I would agree that, architecturally, EKD (ECKD minus the "key") has no more value than FBA and simply adds overhead. > > And, finally, it represents another programming interface that must be > > tested and documented. "Uselessness" is in the eye of the beholder. :-) > > This point does not hold water: > You support the FBA programming interface for V-DISK, not for > (nor even in spite of) idealistic dreaming would-be customers. I thought we were talking about *hardware*something that could take a CD/DVD. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: FCP over ECKD performance advantage - why?
The point gets lost every time Alan and I butt heads on this: FBA disk is byte-for-byte copyable, stamp-it-on-a-CD capable. [E]CKD must retain "out of band" data when copied. But ... to the argument ... > > ...CKD semantics must be simulated by the storage system > > and then peeled off at the O/S end. What a waste! > > Useless? While the operating systems may not be exploiting > the full power of ECKD, applications can. I don't know if DB2 > and VSAM still use keys on the disk to search for data or not. I should have re-iterated "tracks and records" (out of band), which is obviously useful IFF the applications have that level of access, but which are NOT USED by applications on CMS, Linux, or most other operating systems (going beyond zSeries here). So apps don't have access, so is rendered useless if not intrinsically so. If DB2 and VSAM are not using keys (and I believe the latter is not, but am not a VSAM expert) and they're not using the geometric magic (trakcs, records, and such), then they could comparatively run as well or better on FBA or SAN. > [some deleted for brevity] > > But remember that VM/VSE/Linux/UTS/AIX/anything DASD use pales in > comparison to z/OS. That means the mainframe dasd of choice is ECKD. We agree, Alan. > And, finally, it represents another programming interface that must be > tested and documented. "Uselessness" is in the eye of the beholder. :-) This point does not hold water: You support the FBA programming interface for V-DISK, not for (nor even in spite of) idealistic dreaming would-be customers. -- R; -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: FCP over ECKD performance advantage - why?
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Alan Altmark > Sent: Monday, September 11, 2006 12:53 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: FCP over ECKD performance advantage - why? > > Useless? While the operating systems may not be exploiting > the full power > of ECKD, applications can. I don't know if DB2 and VSAM > still use keys on > the disk to search for data or not. > At least on the OS side (starting with OS/VS1, OS/MVS), VSAM never used hardware keys. It always preformatted CIs or CAs with a specific hardware record size without keys. ISAM may have used hardware keys, I don't remember. VSAM KSDS has always been a B+ tree (IIRC). DB2 uses LDSes, accessed via something called "media manager", which is not documented to the unwashed masses such as myself. > > Alan Altmark > z/VM Development > IBM Endicott -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: FCP over ECKD performance advantage - why?
On Sunday, 09/10/2006 at 02:21 AST, Richard Troth <[EMAIL PROTECTED]> wrote: > The real advantage is probably channel speed. And it may be that we'll see > FICON leap-frog past FCP in the future. Speculation. > > I've argued for years that tracks and records are artificial and impose useless > overhead on AIX (remember that?), CMS, Linux, UTS, and even VSE and CP. The > backing store in contemporary DASD is FBA, which is exactly what these > operating systems want. CKD semantics must be simulated by the storage system > and then peeled off at the O/S end. What a waste! Useless? While the operating systems may not be exploiting the full power of ECKD, applications can. I don't know if DB2 and VSAM still use keys on the disk to search for data or not. > I suspect that CKD overhead is heavier on the DASD end, but that's tough to > measure. Still, the measurable difference is probably more in the channels. Other than in the mathematical conversion of block number to CCHHRR based on disk geometry and back, I would expect little to no difference on a typical CCW chain. The cycles spent converting between block number and CCHHRR are dwarfed by all of the cycles spent elsewhere, both in the CPU and the device controller. And the conversions in the controller have not been shown to be causing a bottleneck in dasd access, have they? But remember that VM/VSE/Linux/UTS/AIX/anything DASD use pales in comparison to z/OS. That means the mainframe dasd of choice is ECKD. And, finally, it represents another programming interface that must be tested and documented. "Uselessness" is in the eye of the beholder. :-) Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Any doc on DIAG 204.
On Monday, 09/11/2006 at 10:23ZE5B, "Hariharan T.S." <[EMAIL PROTECTED]> wrote: > Please specify any doc on Diag 204 [Linux kernel module to access PR/SM LPAR > performance data] There is no IBM-provided documentation on Diagnose 0x204. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Hillgang Reminder
A final reminder that the next meeting of the DC-based Linux & VM user group "Hillgang" will take place this Thursday. Thanks to IBM attendees will be treated to a hot breakfast prior to the start of the presentations. http://www.vm.ibm.com/events/hill0914.pdf Neale -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Kernel Compilation Failure with gcc 3.4.6
Heiko, Thanks for your reply. Installing and using two separate versions of gcc on the same system may be a semi-reasonable requirement for a distribution maintainer such as myself. It's a very unreasonable requirement for a distribution user, even a Slackware or Slack/390 one. Further investigation has revealed something fascinating (to me anyway). Just for the sake of completeness, I took all the developerWorks patches, and applied them to a 2.4.21 kernel. The errors I'm seeing about inlining did _not_ show up during the compile. So, I compared the driver/s390/block directories between that and the 2.4.33.2 source trees, and only a few minor, unrelated, differences were seen. Very odd. One error that was consistent, however, was later on (that I didn't see at first, because the compile stopped at dasd_3990_erp.c). I think someone needs to apply this patch: --- linux-2.4.33.2/drivers/s390/misc/chandev.c. 2006-09-10 23:53:31.0 -0400 +++ linux-2.4.33.2/drivers/s390/misc/chandev.c 2006-09-11 01:19:08.0 -0400 @@ -326,7 +326,7 @@ #define chandev_interrupt_check() \ if(in_interrupt())\ - printk(KERN_WARNING __FUNCTION__ " called under interrupt this shouldn't happen\n") + printk(KERN_WARNING " %s called under interrupt this shouldn't happen\n", __FUNCTION__) #define for_each(variable,head) \ Signed-off-by: Mark Post <[EMAIL PROTECTED]> Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Heiko Carstens Sent: Monday, September 11, 2006 1:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Kernel Compilation Failure with gcc 3.4.6 > dasd_int.h:493: sorry, unimplemented: inlining failed in call to > 'dasd_chanq_deq': function body not available > dasd_3990_erp.c:2999: sorry, unimplemented: called from here > > Reducing the optimization level to -O0 didn't help. From my searches on > Google, it appears that a lot of people have run into similar issues > with lots of kernel modules. The only solution seems to have been > removing the inline attribute. If I try to remove the inline attribute > for the function, the problem just crops up in another function. Then > another, and another. Not a good solution, it seems. Tried this with 3.4.5. There are only six bogus inline declarations that you need to remove: three in drivers/s390/block/dasd_int.h and three in drivers/s390/char/tape.h. Afterwards you still need to fix quite a bunch of places to make the kernel compile. IMHO you should install an older compiler on your system as well and use that one for kernel compilation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Kernel Compilation Failure with gcc 3.4.6
Dave, Actually, those are just warnings. The errors are regarding the inlining. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Thomas David Rivers Sent: Monday, September 11, 2006 9:03 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Kernel Compilation Failure with gcc 3.4.6 Mark, GCC is complaining that cast expressions of lvalues is now "gone". This was a GCCism which was in clear violation of the C standard. Newer versions of GCC are "tightening up" the implementation. For example, older versions of GCC would allow something similar to this: int x, y; (char)x = y; which would, on a 390/z-Arch implementation, assign to the most significant byte of the 4 bytes allocated to 'x'. You can imagine, this might be a helpful idiom, but it really is no better than this: char *xp; int x,y; xp = (char *)&x; /* this is "type-punning", which is */ /* only allowed for the char type */ *xp = y; This is the standard C approach to the problem, and makes it easier for an optimizer. I believe you'll have to clean-up your source to be more in-line with ANSI C. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Kernel Compilation Failure with gcc 3.4.6
It appears to be Real Soon Now[tm], but that's just what I believe based solely on Pat's comments in the -current ChangeLog. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Gregg C Levine Sent: Monday, September 11, 2006 8:38 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Kernel Compilation Failure with gcc 3.4.6 -snip- On a side note, I don't suppose you know when 11.0 is going to be ready to be "shipped"? -- Gregg C Levine [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Install WAS Network Deployer 5.1 on SLES9 64-bit
I am trying to install WebSphere AS ND 5.1 on a SLES9 (SP3) 64-bit server. I have the following libraries installed: IBMJava2-SDK-1.4.2-0.60 IBMJava2-JRE-1.4.2-0.60 compat-2004.7.1-1.2 compat-32bit-9-200407011411 During the install, I receive the following message: InstallShield Wizard Initializing InstallShield Wizard... Searching for Java(tm) Virtual Machine... ...A suitable JVM could not be found. Please run the program again using the option -is:javahome It then exits. I was wondering if it is looking for a Java release that I don't have installed? If I do need another Java release, can I install it in addition to the release that is already there? I have successfully installed WAS ND 6.0.2 on this same configuration without incident. - Judson West Teradata, a division of NCR Corporation -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: FCP over ECKD performance advantage - why?
Linux on 390 Port wrote on 09/11/2006 06:01:40 AM: > > The real advantage is probably channel speed. > Not if you compare FICON versus FCP on the same physical adapter. In > effect those are both upper layer protocols on top of the same > transport layer. > > > > Best regards, > Pieter Harder > > [EMAIL PROTECTED] > tel +31-73-6837133 / +31-6-47272537 > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 >From an FCP ucode perspective: * The layout and handling of the QDIO data structures is more conducive to hiding STI latency. * The fibre channel chipset that we use is from a vendor. It has its own ucode, and there are optimized interfaces for FCP Remember, if you look at the storage industry as a whole, FCP is the 800 lb. guerilla. The FCP ucode does take advantage of these optimized interfaces. The IBM storage folks use the same vendor, and there are similar optimized interfaces for FCP targets. Though, I'm not sure of Tuscon's implementation. There are a lot of implementation complexities, and this is not meant to be a complete analysis... Ray Higgs zSeries FCP Development Bld. 706, B24 2455 South Road Poughkeepsie, NY 12601 (845) 435-8666, T/L 295-8666 [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Kernel Compilation Failure with gcc 3.4.6
Mark, GCC is complaining that cast expressions of lvalues is now "gone". This was a GCCism which was in clear violation of the C standard. Newer versions of GCC are "tightening up" the implementation. For example, older versions of GCC would allow something similar to this: int x, y; (char)x = y; which would, on a 390/z-Arch implementation, assign to the most significant byte of the 4 bytes allocated to 'x'. You can imagine, this might be a helpful idiom, but it really is no better than this: char *xp; int x,y; xp = (char *)&x; /* this is "type-punning", which is */ /* only allowed for the char type */ *xp = y; This is the standard C approach to the problem, and makes it easier for an optimizer. I believe you'll have to clean-up your source to be more in-line with ANSI C. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Kernel Compilation Failure with gcc 3.4.6
Hello! Mark when did you update your repository? On a non local Slackware mirror, the one maintained down under on the Planet Mirror one, I found a newer kernel, this one is 2.4.33.3 try that one if you are interested in seeing if this bug has been fixed. I suspect that this is true for both platforms. Intel and S390 or S390x if you are leaning in the same direction as I surmise you are. Naturally the local one to us, the Ibiblio.org one might also be wearing the same one. But for reasons that will take way too long to go into, I prefer to use the one in Oz when ever it necessary. (And yes folks I mean that the mirror is based someplace in Australia.) On a side note, I don't suppose you know when 11.0 is going to be ready to be "shipped"? -- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you. Always." Obi-Wan Kenobi > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Post, > Mark K > Sent: Sunday, September 10, 2006 11:32 PM > To: LINUX-390@VM.MARIST.EDU > Subject: [LINUX-390] Kernel Compilation Failure with gcc 3.4.6 > > I'm trying to compile the 2.4.33.2 kernel with gcc 3.4.6, and I'm > getting a compilation error (shown below). The same code compiles with > gcc 3.3.4, so I went looking for a gcc bug. I think I found it at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14756. The problem I have > is that the patch shown for that bug report: > - doesn't apply cleanly > - if tweaked to apply, the updated cgraphunit.c module doesn't compile > > The kernel compile error is this: > make[3]: Entering directory > `/tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/drivers/s390/block' > ld -m elf64_s390 -r -o dasd_mod.o dasd.o > gcc -D__KERNEL__ > -I/tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common > -fomit-frame-pointer -pipe -fno-strength-reduce -nostdinc -iwithprefix > include -DKBUILD_BASENAME=dasd_3990_erp -c -o dasd_3990_erp.o > dasd_3990_erp.c > In file included from dasd_3990_erp.c:15: > /tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/include/asm/idals.h: > In function `idal_buffer_to_user': > /tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/include/asm/idals.h: > 231: warning: use of cast expressions as lvalues is deprecated > /tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/include/asm/idals.h: > 231: warning: use of cast expressions as lvalues is deprecated > /tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/include/asm/idals.h: > In function `idal_buffer_from_user': > /tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/include/asm/idals.h: > 252: warning: use of cast expressions as lvalues is deprecated > /tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/include/asm/idals.h: > 252: warning: use of cast expressions as lvalues is deprecated > dasd_3990_erp.c: In function `dasd_3990_erp_handle_match_erp': > dasd_int.h:493: sorry, unimplemented: inlining failed in call to > 'dasd_chanq_deq': function body not available > dasd_3990_erp.c:2999: sorry, unimplemented: called from here > make[3]: *** [dasd_3990_erp.o] Error 1 > make[3]: Leaving directory > `/tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/drivers/s390/block' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory > `/tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/drivers/s390/block' > make[1]: *** [_subdir_block] Error 2 > make[1]: Leaving directory > `/tmp/kernel-default-2.4.33.2/usr/src/linux-2.4.33.2/drivers/s390' > make: *** [_dir_drivers/s390] Error 2 > > > Reducing the optimization level to -O0 didn't help. From my searches on > Google, it appears that a lot of people have run into similar issues > with lots of kernel modules. The only solution seems to have been > removing the inline attribute. If I try to remove the inline attribute > for the function, the problem just crops up in another function. Then > another, and another. Not a good solution, it seems. > > It looks like the Intel version of Slackware 11.0 is going to ship with > gcc 3.4.6 as the default compiler, so I'd prefer to stay with that > version myself, if possible. Is there a better fix to gcc 3.4.6 (or the > kernel?) that would resolve this problem? > > > Thanks, > > Mark Post > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: FCP over ECKD performance advantage - why?
Pieter Harder wrote: there are a number of sources that indicate that FCP attached DASD performs better than classic ECKD DASD. My own numbers seem to confirm this. But I am wondering what exactly is the advantage that FCP has over ECKD? The major difference can be found on the protocol level. FCP is a queueing protocol that allows to submit more I/O while the device is processing. The same effect can be archived by doing PAV with FICON devices. Carsten thinks, that both protocols are equally fast enough for not being a bottleneck when set up proper. cheers, Carsten -- Carsten Otte has stopped smoking: Ich habe in 3 Monate, 2 Wochen und 3 Tage schon 527,27 Euro gespart anstatt 2.196,97 Zigaretten zu kaufen. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: FCP over ECKD performance advantage - why?
> The real advantage is probably channel speed. Not if you compare FICON versus FCP on the same physical adapter. In effect those are both upper layer protocols on top of the same transport layer. Best regards, Pieter Harder [EMAIL PROTECTED] tel +31-73-6837133 / +31-6-47272537 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
