On Tue, 4 Aug 2020 09:33:38 +0200
Stefan Raspl wrote:
> Hi Tim,
> Thanks for your feedback, your thoughts are greatly appreciated!
>
> On 2020-08-04 07:56, Timothy Sipples wrote:
> > Would this readout make better sense?
> >
> > $ zhypinfo
> > NoLayer TypeName
On Fri, 5 Jun 2020 16:34:20 +1000
Peter Bishop wrote:
> Hi,
>
> when I try to browse this link to use the web archives
>
> http://vm.marist.edu/htbin/wa?A0=LINUX-390
>
> I get an error, seemingly from the server (?).
>
> Unknown/Unsupported option A0=LINUX-390
>
>
>
> End of page
>
>
Lo
On Thu, 19 Dec 2019 13:06:24 +
Neale Ferguson wrote:
> And thus was born cio_ignore?
Well, that was my second kernel patch :) (And the oldest one still
existing in remnants -- /proc/subchannels only lived during the 2.4 era
-- although the current cio_ignore implementation is a far cry from
On Fri, 13 Jul 2018 14:38:44 -0500
Phillip Gramly wrote:
I'm seconding the suggestion of using chzdev, but some additional notes
from me:
> # vmcp q v 204-206
> OSA 0204 ON NIC 0204 UNIT 000 SUBCHANNEL = 0001
> 0204 DEVTYPE HIPER VIRTUAL CHPID 01 IQD
> 0204 MAC 02-00-00-00-00-
On Wed, 18 Feb 2009 21:03:59 +0100,
Ivan Warren wrote:
> - IPL time ensuing from having many thousand devices (Lordy.. Issuing
> Sense-ID, RDC and read of cyl 0 track 1 - on 1 devices shouldn't
> take but a couple seconds anyway.. What's wrong here.. all modern OSes
> do this in a routine
On Wed, 6 Feb 2008 10:43:32 -0500,
David Boyes <[EMAIL PROTECTED]> wrote:
> > > That seems kind of counter-intuitive. A device clearly just changed
> > > state in an important way -- shouldn't that be something udev should
> > > care about, or at least be notified of? Udev can always choose to
> i
On Wed, 6 Feb 2008 09:12:42 -0500,
David Boyes <[EMAIL PROTECTED]> wrote:
>
> > zfcp does not create any udev/hotplug events. Related events are:
> > - The CCW device is attached to the system
> > - The CCW device is removed from the system.
> > - A SCSI host adapter is registered from zfcp.
>
On Thu, 3 Jan 2008 17:16:49 +0200,
Niemi Ari <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've got three Linuxes installed on LPARs, so z/VM is not used.
> Distributions on all of those are CentOS 4.5 with 2.6.9 kernel. Two of
> these have 1 GB memory per LPAR and one has 256 MB. The hardware is z9
> E
On Thu, 27 Sep 2007 11:52:37 +0200,
"Ceruti, Gerard G" <[EMAIL PROTECTED]> wrote:
> It show a long list of DASD that can be seen but not the UCB I need , looking
> further I see all the DASD devices are linked to CSS0, we have 2 CSS defined
> and the UCB I am looking for is defined in the HCD G
On Tue, 31 Jul 2007 13:02:16 -0400,
David Boyes <[EMAIL PROTECTED]> wrote:
> > You should also use cio_ignore= to ignore all devices you might want
> to
> > use later but not now. The major issue (besides regulating access) is
> > not IPL time (though applications like HAL are extremely slow to st
On Tue, 31 Jul 2007 09:52:31 -0400,
David Boyes <[EMAIL PROTECTED]> wrote:
> Also, define ONLY the
> devices that Linux will be allowed to use. If you share all devices,
> your Linux will a) take forever to IPL, and b) have unfettered access to
> all your data. Linux pays no attention to any z/OS
(i = 0; i < ARRAY_SIZE(vm_devices); i++)
> if (diag_data.vrdcvcla == vm_devices[i].vrdcvcla &&
> diag_data.vrdcvtyp == vm_devices[i].vrdcvtyp) {
> ps->cu_type = vm_devices[i].cu_type;
>
>
Acked-by: Cornelia Huck <[EM
character device,
which will trigger device node creation.
--
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email
ux can see the device but can't
talk to it (this could indicate a cabling problem or such). If you
don't even see the "Detected device ..." messages, this means Linux
can't even see the device (you should make sure it isn't included in
any cio_ignore= statement).
--
Corn
te? Current git just compiled fine with SMP=n
for me.
--
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [
On Thu, 6 Apr 2006 22:15:19 -0400
Neale Ferguson <[EMAIL PROTECTED]> wrote:
> It's not the tape error per se but the code in the kernel. X'' will give
> you an operation exception and the kernel will throw up its hands and give
> up.
That's the expected behaviour since the code threw a BUG(),
On Thu, 30 Mar 2006 13:59:45 +0200
Fuhrmann Anna <[EMAIL PROTECTED]> wrote:
> We want to implement Hipersockets and I am looking it up in the IBM
> Redbook SG246816.
This Redbook looks a bit old; the Linux information in it is for 2.4
kernels. I hope you try to implement this in RHEL4 and not in
On Tue, 21 Mar 2006 12:11:40 -0500
Brian Nelson <[EMAIL PROTECTED]> wrote:
> Also, does anyone know if the IBM developers are planning on releasing a
> 3590 OCO module for 2.6.16?
This one (posted a few moments ago) might even be better than an OCO :)
http://marc.theaimsgroup.com/?l=linux-kernel
> I think we would have swapped the cards without varying off the channel.
> Possibly a mid-flight I/O hung Linux. That was SuSE8 / Linux 2.4x kernel.
2.4 might have still had some problems in this area.
> BTW, how do you start/stop the channels?
>
> I see /sys/devices/css0/chp0.2e/status and
> /
On Mon, 20 Feb 2006 14:51:33 -0700
Dave Czajkowski <[EMAIL PROTECTED]> wrote:
> Using the HMC, I configured offline some z990 Ficon dasd chpids to a native
> SLES8 64-bit (2.4.21-304) lpar. /proc/chpids now shows those chpids as
> n/a. After configuring back online , I tried to issue echo on 20
On Sat, 18 Feb 2006 17:53:39 -0800
Ranga Nathan <[EMAIL PROTECTED]> wrote:
> That is nice to know. However when we swapped cards some time ago when
> Linux was running on bare metal, we had problems. Perhaps we did not
> vary off the channel on the linux lpar before we swapped the cards?
Was this
On Thu, 3 Nov 2005 11:02:23 -0500
"Hall, Ken (GTI)" <[EMAIL PROTECTED]> wrote:
> We used to see behavior like this on our SLES8 systems, when too many
> images were brought up at once. It seemed to be related to contention
> for the disks because we'd reboot the images independently and they'd
>
ome problems with scripts...) - this construct will never work
with the current misc device implementation.
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
--
t used to be a seperate major in older drivers.)
SUSE should have scripts in place which will generate the correct device
file under /dev (just check if there is a /dev/crypto available).
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837,
, if you have a
kernel with devfs support, I'm not sure).
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
--
For LINUX-390 subscribe /
ot;qeth0" for both devices, they'll both get the interface number
0.
It would work if one were, for example, eth0 and the other tr0...
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
T
39:57 theuniverse kernel: Terminating lcs module.
The only idea I have left is to double-check your chandev.conf -
but if it is the same as you wrote in your first mail, it is fine.
Or try to manually pipe the information into /proc/chandev and
reload the module?
Best regards / Mit freundlichen Grues
mesg?
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL
afterwards).
After you load the lcs module, you could then check /proc/s39dbf/lcs/ for
any hints on what went wrong.
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
---
ing lcs to keep it loaded even if it fails to initialize any devices).
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
--
For LINUX-390 subscribe
Your interface is speaking raw ip while pretending to be an ethernet
device (well, it is close in other respects...)
You should check the latest device driver manual from DeveloperWorks
for a patch to libpcap that helps with qeth devices.
Best regards / Mit freundlichen Gruessen
Cornelia Huck
_SLAB, as this breaks our ccw alignment.
Best regards / Mit freundlichen Gruessen
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
Best regards / Mit freundlichen Gruessen
Cornelia Huck
zLinux Developer
Tel.: +49-7031-16-4837, Mail: [EMAIL PROTECTED]
|-+>
| | "Post, Mark K" |
| | <[EMAIL PROTECTED]|
| | m> |
ckets)
There was a VM bug which caused this, but I can't remember offhand the APAR
number... anyway, this has been fixed for some time.
Mit freundlichen Grüßen/Regards
Cornelia Huck
Linux for zSeries Development
IBM Deutschland Entwicklung GmbH
Email: [EMAIL PROTECTED]
Phone: ext. +49(0)7031/16
s and the ability to set
chpids logically offline).
Mit freundlichen Grüßen/Regards
Cornelia Huck
Linux for zSeries Development
IBM Deutschland Entwicklung GmbH
Email: [EMAIL PROTECTED]
Phone: ext. +49(0)7031/16-4837, int. *120
,
though) - but it shouldn't
hurt to specify one. Portnames are always upper case.
Mit freundlichen Grüßen/Regards
Cornelia Huck
Linux for zSeries Development
IBM Deutschland Entwicklung GmbH
Email: [EMAIL PROTECTED]
Phone: ext. +49(0)7031/16-4837, int. *120-4837
lready set). Path grouping was
and is done on all multipath devices that support it.
Without this APAR, "access boxed dasd" will not work for minidisks; path
grouping is fine for all but minidisks. But you should still apply the
APAR.
Mit freundlichen Grüßen/Regards
Cornelia Huc
0" or "" for CU type, could you please try to setup
a trace for the device
(#cp tr io inst int ccw run) and send me the output after the
attach?
Mit freundlichen Grüßen/Regards
Cornelia Huck
Linux for zSeries Development
IBM Deutschland Entwicklung GmbH
Email: [EMAIL PROTECTED]
Ph
your dasds? (Check with
#cp q paths to ) If so, you might try to vary the ailing path(s)
offline completely and try if the system will come up then.
Mit freundlichen Grüßen/Regards
Cornelia Huck
Linux for zSeries Development
IBM Deutschland Entwicklung GmbH
Email: [EMAIL PROTECTED]
Phone: ext. +49(0
Hi,
the tape reporting a cu_type of 3990 looks very odd... how does the device
show up in /proc/subchannels?
Also, /proc/s390dbf/cio_msg/sprintf might hold some interesting info after
the attach of the device.
Mit freundlichen Grüßen/Regards
Cornelia Huck
Linux for zSeries Development
IBM
40 matches
Mail list logo
