Having problems replying to posts
Hello from Gregg C Levine Here's my problem. My ISP had a traumatic event from the severe weather from this week. I'd like to be able to reply to some posts, including the one from William Scully, regarding the 2.6 family problems he's been having since I recognized them from my own work. Is there a web interface to the list, so that I can physically respond that way? How can I use it, do I need to register? My ISP should recover from this event RSN. That's also why you've been seeing those annoying test messages. --- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi -- 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
Test again
Hello from Gregg C Levine We are still having problems. Please ignore this message. -- 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: Domino 6.5 performance a little disappointing on zLinux
> Comparisons between an in house Domino app when run on a 800Mhz Wintel > with 500MB RAM versus a SLES8 zLinux guest machine with 256MB > storage and > 300MB of VDISK swap on an almost idle 192 MIP IFL show the Wintel box > processing about 3 times faster. The numbers are coming from > the Domino > web log. > Anyone else experience the same? Yeah, that's what we saw in testing too. It's not too surprising. Most Domino apps tend to be CPU- and numerically- intensive (think about what's doing all that script interpretation and graphical stuff, and how much of it assumes/requires heavy floating-point calculation), so you're seeing the slower CPU speed of the 390. Cycles aren't infinite on the 390, and Lotus doesn't compensate well. Domino's OK for mail on the 390 platform, but it's no gem for applications. If you get a chance, try running the app from the dedicated Windows client against the 390 server and compare results. Some of the performance difference should go away for the things that can be offloaded to the client processor. May not help in your situation, but it tends to point up where Lotus needs to do some work on Domino on platforms where CPU isn't infinite or free. -- db -- 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: Linux 2.6.7 Patch Status (LONG)
Mark Post wrote: >Again, I'm at >http://www10.software.ibm.com/developerworks/opensource/linux390/april2004_r >ecommended.shtml, and in the 'kernel downloads for the "April 2004 stream":' >section, I only see links for the full patches as you describe them: >linux-2.6.5-s390-base-april2004.tar.gz (MD5) >linux-2.6.5-s390-01-april2004.tar.gz (MD5) >xipfs612.gz + xipfs622.gz (from: linuxvm.org/patches/index.html) >linux-2.6.5-s390-02-april2004.tar.gz (MD5) >linux-2.6.5-s390-03-april2004.tar.gz (MD5) >Single threaded workqueue patch (from: linux.bkbits.net:8080/linux-2.5/) >linux-2.6.5-s390-04-april2004.tar.gz (MD5) >linux-2.6.5-s390-05-april2004.tar.gz (MD5) Yes, and to the immediate right of each of these links, under the table heading "Description", are links to one page per patch, each providing both detailed descriptions of the contents of the patch as well as broken up small patches for every separate change contained within the big patch. Alternatively, you can reach those same pages from lower down the page under the heading "Download Area for April 2004 stream". >The current version may very well be "Linus' BK head," but that's not where >everyone gets told to go to for Linux/390 patches. Well, what "everyone gets told" by us is how to find the officially supported service stream, on developerWorks. I'm now getting confused as to what you're actually asking for ... >Publish some >documentation on how to retrieve that and I probably won't be bothering the >list much more in the future. The official Linux kernel tree is hosted on http://linux.bkbits.net; you can browse the source tree as well as change logs online, or you can use bitkeeper to download a copy. (There's also a link to bitmover, the company that provides bitkeeper, that has detailed information on how to get and use bitkeeper). If you don't like bitkeeper, you can also download daily snapshots from ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots. (All this is just standard Linux kernel development, nothing to do with IBM. But that was actually the point, we want to stop doing special things ...) Bye, Ulrich -- Dr. Ulrich Weigand [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
Domino 6.5 performance a little disappointing on zLinux
Comparisons between an in house Domino app when run on a 800Mhz Wintel with 500MB RAM versus a SLES8 zLinux guest machine with 256MB storage and 300MB of VDISK swap on an almost idle 192 MIP IFL show the Wintel box processing about 3 times faster. The numbers are coming from the Domino web log. There's a field in the log that tracks processing time per request. Unfortunately, same request (agent) run on each platform runs faster on the Wintel. The IFL is definitely not strained during the comparison. I haven't yet employed the LVM striping performance enhancement, however, I'm not sure it will help in this case. Anyone else experience the same? Matt Lashley Idaho State Controller's Office -- 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: Linux 2.6.7 Patch Status (LONG)
Hi Mark, On the '"April 2004 stream" RECOMMENDED downloads' page under 'kernel downloads for the "April 2004 stream' is a table of links with three columns labeled Package, Downloads and Description. The link in the Description field will take you to a page that will allow you to download either the "... accumulated patch" or the "... per-problem-patches". Best regards, Bill Stermer -- 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: Linux 2.6.7 Patch Status (LONG)
Again, I'm at http://www10.software.ibm.com/developerworks/opensource/linux390/april2004_r ecommended.shtml, and in the 'kernel downloads for the "April 2004 stream":' section, I only see links for the full patches as you describe them: linux-2.6.5-s390-base-april2004.tar.gz (MD5) linux-2.6.5-s390-01-april2004.tar.gz (MD5) xipfs612.gz + xipfs622.gz (from: linuxvm.org/patches/index.html) linux-2.6.5-s390-02-april2004.tar.gz (MD5) linux-2.6.5-s390-03-april2004.tar.gz (MD5) Single threaded workqueue patch (from: linux.bkbits.net:8080/linux-2.5/) linux-2.6.5-s390-04-april2004.tar.gz (MD5) linux-2.6.5-s390-05-april2004.tar.gz (MD5) Apparently I need to go somewhere else to find the per-patch tarballs. Where is that? The current version may very well be "Linus' BK head," but that's not where everyone gets told to go to for Linux/390 patches. Publish some documentation on how to retrieve that and I probably won't be bothering the list much more in the future. If I can find all the pieces to this puzzle, then I'll publish the patches against the current version, as I find time to do them. It would be nicer if they came from the developerWorks site, but oh well. Mark Post -Original Message- From: Ulrich Weigand [mailto:[EMAIL PROTECTED] Sent: Friday, July 16, 2004 10:03 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Linux 2.6.7 Patch Status (LONG) Mark Post wrote: > Ummm, no. When you unpack linux-2.6.5-s390-04-april2004.tar.gz, you > get two files, linux-2.6.5-s390-04-april2004.diff, and .readme. Well, yes, but that is the *full* patch. Specifically in order to make back-and-forth porting easier, however, we always provide a *per-problem* (or per-feature as may be) break-up of the big patch into multiple small patches. This can be downloaded by clicking on the *second* 'Download' button; the one with 'per problem' next to it (as I wrote below). > Moreover, there is no way to look at the 47,000 lines of patches in > those files and determine which lines belong to The kerntypes patch > The multicast notifier patch > The zfcp module_exit vs. lun/port object kfree patch > The shared-IPv6-card patch > The lost-dirty-bit fix Very true; and indeed exactly the reason why we provide per-problem patches ;-) > I just want some way of checking which version of a source code module > is considered by the developers to be current. From there, I can > figure out what the 2.6.7 (or whatever) version is supposed to look > like when I'm done. I don't need to see IBM OCO code, or unreleased > features, etc., etc. The 'current' version is the one in Linus' current Bitkeeper head. > If things are to the point where it is feasible (and you make it sound > like it is), I think it may be time to start publishing patch sets > against what ever version is current from kernel.org, and not keep > putting them out against 2.6.5 (or what ever milestone release has > been set). _That_ would make things a lot easier. Our current procedure is to produce patches against Bitkeeper head (ready for inclusion), and backport them (if appropriate) to apply against our developerWorks service stream. We do not generate additional backports against other official kernel releases, because that would be a lot of additional work. Either use the service stream, wait for inclusion in the next official release, or backport yourself ... Bye, Ulrich -- Dr. Ulrich Weigand [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
AW: Performance of large file systems
I am sorry, I dont want to get that wrong: You are really using PAV since 4 years? You are able to access ONE Dasd parallel over multiple different escon channels at the same time? What I/O did you measure? We get 6-9 MB/sec with "normal" access, until 30-40 MB/s over 8 Channels and 8 Stripes in an LVM with 8 DASDs... Do you really have more than 10 MB/sec when accessing ONE seperate Dasd? regards > Frank Schwede > Lufthansa Systems Infratec GmbH > > http://www.LHsystems.com > -Ursprüngliche Nachricht- Von: Linux on 390 Port [mailto:[EMAIL PROTECTED] Auftrag von N. Blekemolen Gesendet: Freitag, 16. Juli 2004 15:22 An: [EMAIL PROTECTED] Betreff: Re: Performance of large file systems Only for the last four years :-)... Nico Blekemolen TMI Dagblad De Telegraaf "Ledbetter, Scott E" <[EMAIL PROTECTED]> Verzonden door: Linux on 390 Port <[EMAIL PROTECTED]> 16-07-2004 14:47 Antwoord a.u.b. aan Linux on 390 Port <[EMAIL PROTECTED]> Aan [EMAIL PROTECTED] Cc Onderwerp Re: [LINUX-390] Performance of large file systems I guess I have made an incorrect assumption here. I'm in my own little world, where in our product (StorageTek SVA) FICON and PAV are married. I'm guessing most people using PAV are also using FICON. I'll throw it out: Anyone using PAV on a DASD box with ESCON? Scott Ledbetter StorageTek -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Bergmann Sent: Friday, July 16, 2004 1:54 AM To: [EMAIL PROTECTED] Subject: Re: Performance of large file systems Scott Ledbetter wrote: >Since you are ESCON, you are not PAV capable I am unaware of this restriction, where did you find it? Klaus Bergmann Linux Architecture and Performance, IBM Lab Boeblingen -- 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 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ** -- 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: Linux 2.6.7 Patch Status (LONG)
Mark Post wrote: > Ummm, no. When you unpack linux-2.6.5-s390-04-april2004.tar.gz, you get two > files, linux-2.6.5-s390-04-april2004.diff, and .readme. Well, yes, but that is the *full* patch. Specifically in order to make back-and-forth porting easier, however, we always provide a *per-problem* (or per-feature as may be) break-up of the big patch into multiple small patches. This can be downloaded by clicking on the *second* 'Download' button; the one with 'per problem' next to it (as I wrote below). > Moreover, there is no way to look at the 47,000 lines of patches in those > files and determine which lines belong to > The kerntypes patch > The multicast notifier patch > The zfcp module_exit vs. lun/port object kfree patch > The shared-IPv6-card patch > The lost-dirty-bit fix Very true; and indeed exactly the reason why we provide per-problem patches ;-) > I just want some way of checking which version of a source code module is > considered by the developers to be current. From there, I can figure out > what the 2.6.7 (or whatever) version is supposed to look like when I'm done. > I don't need to see IBM OCO code, or unreleased features, etc., etc. The 'current' version is the one in Linus' current Bitkeeper head. > If things are to the point where it is feasible (and you make it sound like > it is), I think it may be time to start publishing patch sets against what > ever version is current from kernel.org, and not keep putting them out > against 2.6.5 (or what ever milestone release has been set). _That_ would > make things a lot easier. Our current procedure is to produce patches against Bitkeeper head (ready for inclusion), and backport them (if appropriate) to apply against our developerWorks service stream. We do not generate additional backports against other official kernel releases, because that would be a lot of additional work. Either use the service stream, wait for inclusion in the next official release, or backport yourself ... Bye, Ulrich -- Dr. Ulrich Weigand [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: Linux 2.6.7 Patch Status
No, I'm not looking at the -patches variant. Where would that be located? I just looked and didn't see that anywhere on http://www10.software.ibm.com/developerworks/opensource/linux390/april2004_r ecommended.shtml Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schwidefsky Sent: Friday, July 16, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: Re: Linux 2.6.7 Patch Status Hi Mark, > No, that's not the name inside the tarball. See my note to Ulrich (or > download the file yourself if you don't believe me). As I also said > to Ulrich, even if that were the name of the file, I have no way of > knowing which lines actually comprise _just_ the "multicast notifier > patch." So I have no way of only adding that on top of 2.6.8-rc1. Are you looking at the linux-2.6.5-s390-xxx-april2004.tar.gz tarball or at the linux-2.6.5-s390-xxx-april2004-patches.tar.gz tarball ? You'll find the per-problem patches only in the -patches variant. blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: [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 -- 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: Linux 2.6.7 Patch Status
Hi Mark, > No, that's not the name inside the tarball. See my note to Ulrich (or > download the file yourself if you don't believe me). As I also said to > Ulrich, even if that were the name of the file, I have no way of knowing > which lines actually comprise _just_ the "multicast notifier patch." So I > have no way of only adding that on top of 2.6.8-rc1. Are you looking at the linux-2.6.5-s390-xxx-april2004.tar.gz tarball or at the linux-2.6.5-s390-xxx-april2004-patches.tar.gz tarball ? You'll find the per-problem patches only in the -patches variant. blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: [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: Linux 2.6.7 Patch Status
No, that's not the name inside the tarball. See my note to Ulrich (or download the file yourself if you don't believe me). As I also said to Ulrich, even if that were the name of the file, I have no way of knowing which lines actually comprise _just_ the "multicast notifier patch." So I have no way of only adding that on top of 2.6.8-rc1. I need to be able to insmod and rmmod any module, since I'm building distributions. Having to reboot to get rid of a module is not acceptable to me. I'll look over the details of your reply, but I'm not sure that I will be able to do what I want, even with this level of information. If the diffs for 2.6.7 are really that small, putting them up on developerWorks should be no big deal, right? :) And then 2.6.8 should be even easier. ;) Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Arnd Bergmann Sent: Friday, July 16, 2004 8:36 AM To: [EMAIL PROTECTED] Subject: Re: Linux 2.6.7 Patch Status (LONG) On Freitag, 16. Juli 2004 00:32, Post, Mark K wrote: > 1. You're using names for patches that aren't publicly known, such as > "The multicast notifier patch - linux-2.6.5-s390-04-26-april2004.diff" Huh? That's the file name inside the patch tarball on developerWorks. Where else did you get your patches if not there? > 2. You talk of partial reversions, but I have no way of knowing what > parts of what patch were reverted, and which were kept. In case of the zfcp patch, the history is documented in any lkml archive. The developerWorks version of that driver contains a hack to allow module unloading that was not accepted into 2.6.6. The driver works perfectly fine without that patch, you just can't unload the module, but you should not have any reason to do that anyway. -snip- -- 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: Performance of large file systems
Only for the last four years :-)... Nico Blekemolen TMI Dagblad De Telegraaf "Ledbetter, Scott E" <[EMAIL PROTECTED]> Verzonden door: Linux on 390 Port <[EMAIL PROTECTED]> 16-07-2004 14:47 Antwoord a.u.b. aan Linux on 390 Port <[EMAIL PROTECTED]> Aan [EMAIL PROTECTED] Cc Onderwerp Re: [LINUX-390] Performance of large file systems I guess I have made an incorrect assumption here. I'm in my own little world, where in our product (StorageTek SVA) FICON and PAV are married. I'm guessing most people using PAV are also using FICON. I'll throw it out: Anyone using PAV on a DASD box with ESCON? Scott Ledbetter StorageTek -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Bergmann Sent: Friday, July 16, 2004 1:54 AM To: [EMAIL PROTECTED] Subject: Re: Performance of large file systems Scott Ledbetter wrote: >Since you are ESCON, you are not PAV capable I am unaware of this restriction, where did you find it? Klaus Bergmann Linux Architecture and Performance, IBM Lab Boeblingen -- 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 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ** -- 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: Performance of large file systems
On Friday 16 July 2004 08:47, you wrote: > > I'll throw it out: Anyone using PAV on a DASD box with ESCON? > Absolutely. 12 Escon into Shark #1, 4 FICON into Shark #2. -- 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: Performance of large file systems
I guess I have made an incorrect assumption here. I'm in my own little world, where in our product (StorageTek SVA) FICON and PAV are married. I'm guessing most people using PAV are also using FICON. I'll throw it out: Anyone using PAV on a DASD box with ESCON? Scott Ledbetter StorageTek -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Bergmann Sent: Friday, July 16, 2004 1:54 AM To: [EMAIL PROTECTED] Subject: Re: Performance of large file systems Scott Ledbetter wrote: >Since you are ESCON, you are not PAV capable I am unaware of this restriction, where did you find it? Klaus Bergmann Linux Architecture and Performance, IBM Lab Boeblingen -- 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: Linux 2.6.7 Patch Status (LONG)
On Freitag, 16. Juli 2004 00:32, Post, Mark K wrote:
> 1. You're using names for patches that aren't publicly known, such as "The
> multicast notifier patch - linux-2.6.5-s390-04-26-april2004.diff"
Huh? That's the file name inside the patch tarball on developerWorks.
Where else did you get your patches if not there?
> 2. You talk of partial reversions, but I have no way of knowing what parts
> of what patch were reverted, and which were kept.
In case of the zfcp patch, the history is documented in any lkml archive.
The developerWorks version of that driver contains a hack to allow module
unloading that was not accepted into 2.6.6. The driver works perfectly fine
without that patch, you just can't unload the module, but you should not
have any reason to do that anyway.
> This gets real long, so I apologize for that.
No problem. However, when you are commenting a patch, please put the
comments behind the code like in a mail conversation.
> I guess I would like to repeat my request for a copy of the current versions
> of the S/390 files as known today. I would have been able to figure out
> most of this myself if I had that for a reference.
For reference, look at the code in 2.6.8-rc1, and add the four patches
Martin mentioned if you wish.
> - - - - - - - - - - - - - - -
>
> Is this the patch Martin partially reverted? I think it's the shared IPV6
> card stuff.
Yes. If you want to share cards using IPv6 over multiple z/VM guests,
you need to apply the patch that adds these fields.
> drivers/net/net_init.c
> diff -urN linux-2.6/drivers/net/net_init.c
> linux-2.6-s390/drivers/net/net_init.c
> --- linux-2.6/drivers/net/net_init.cSun Apr 4 05:36:16 2004
> +++ linux-2.6-s390/drivers/net/net_init.c Tue Apr 13 10:35:19 2004
> @@ -277,7 +277,8 @@
> dev->hard_header_cache = eth_header_cache;
> dev->header_cache_update= eth_header_cache_update;
> dev->hard_header_parse = eth_header_parse;
> -
> + dev->generate_eui64 = NULL;
> + dev->dev_id = 0;
> dev->type = ARPHRD_ETHER;
> dev->hard_header_len= ETH_HLEN;
> dev->mtu= 1500; /* eth_mtu */
> @@ -303,6 +304,8 @@
> dev->change_mtu = fddi_change_mtu;
> dev->hard_header= fddi_header;
> dev->rebuild_header = fddi_rebuild_header;
> + dev->generate_eui64 = NULL;
> + dev->dev_id = 0;
>
> dev->type = ARPHRD_FDDI;
> dev->hard_header_len= FDDI_K_SNAP_HLEN+3; /* Assume 802.2 SNAP
> hdr len + 3 pad bytes *
> /
> @@ -413,6 +416,8 @@
>
> dev->hard_header= tr_header;
> dev->rebuild_header = tr_rebuild_header;
> + dev->generate_eui64 = NULL;
> + dev->dev_id = 0;
>
> dev->type = ARPHRD_IEEE802_TR;
> dev->hard_header_len= TR_HLEN;
>
> The version number on the 2.6.7 file is older, but the date is newer.
> Which versions of the structs are supposed to be correct?
It does not matter except for checking the source code with the 'sparse'
tool. The 2.6.7 version is correct, but there is no point in backporting
since this does not cause a bug in the binary.
> drivers/s390/block/dasd_cmb.c
> --- linux-2.6.5/drivers/s390/block/dasd_cmb.c 2004-07-08
> 18:50:03.0 -0400
> +++ linux-2.6.7/drivers/s390/block/dasd_cmb.c 2004-06-16
> 01:19:36.0 -0400
> @@ -1,5 +1,5 @@
> /*
> - * linux/drivers/s390/block/dasd_cmb.c ($Revision: 1.7.2.1 $)
> + * linux/drivers/s390/block/dasd_cmb.c ($Revision: 1.6 $)
> *
> * Linux on zSeries Channel Measurement Facility support
> * (dasd device driver interface)
> @@ -58,7 +58,7 @@
> dasd_ioctl_readall_cmb(struct block_device *bdev, int no, long args)
> {
> struct dasd_device *device;
> - struct cmbdata * __user udata;
> + struct cmbdata __user *udata;
> struct cmbdata data;
> size_t size;
> int ret;
> @@ -66,7 +66,7 @@
> device = bdev->bd_disk->private_data;
> if (!device)
> return -EINVAL;
> - udata = (void *) args;
> + udata = (void __user *) args;
> size = _IOC_SIZE(no);
>
> if (!access_ok(VERIFY_WRITE, udata, size))
>
> This patch, dated June 17th, appears to revert (or be reverted by) the
> code in 2.6.7, dated June 16th. 2.6.7 file is version 1.55, 2.6.5 is
> 1.53.2.3?
2.6.5 version is correct. This minor bug fix came too late for 2.6.7 but is
merged in 2.6.8-rc1.
> --- linux-2.6.5/drivers/s390/block/dasd_eckd.c 2004-07-08
> 18:50:03.0 -0400
> +++ linux-2.6.7/drivers/s390/block/dasd_eckd.c 2004-06-16
> 01:18:38.0 -0400
> @@ -7,7 +7,7 @@
> * Bugreports.to..: <[EMAIL PROTECTED]>
> * (C) IBM Corporation, IBM Deutschland Entwicklung GmbH, 1999,2000
> *
> - * $Revision: 1.53.2.3 $
> + * $Revision: 1.55 $
> */
>
> #in
Re: Linux 2.6 Kernel
On Donnerstag, 15. Juli 2004 21:48, Scully, William P wrote: > My goal is to force certain directories in the tree to be R/O instead of > R/W. But I'm at a loss as to where "getpt" is looking such that it says > "No such file...". I thought it was in /dev, but I'm *-certain-* /dev > is R/W. Could it be that your /dev/pts is mounted on the original /dev, not the rw bind mount? Arnd <>< -- 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 pgpmcf2LXjbnw.pgp Description: signature
Re: Performance of large file systems
Scott Ledbetter wrote: >Since you are ESCON, you are not PAV capable I am unaware of this restriction, where did you find it? Klaus Bergmann Linux Architecture and Performance, IBM Lab Boeblingen -- 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
