* PowerDomain 3940UWD
@ 1999-09-09 17:14 Ryuichi Oikawa
1999-09-09 18:14 ` Michel Lanners
0 siblings, 1 reply; 5+ messages in thread
From: Ryuichi Oikawa @ 1999-09-09 17:14 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I've tried Adaptec PowerDomain 3094UWD, dual channel UW SCSI card
with PCI-PCI bridge and two SCSI controllers under the bridge,
and I noticed driver related and OF related problems.
First I tried vger 2.2.12 kernel that caused machine check exception
at first IO write transaction. I thought that this was normal because
OF didn't properly set up P2P bridge's IO forwarding window.
The real problem was this part(aic7xxx.c):
#ifdef MMAPIO
if ( !(temp_p->flags & AHC_MULTI_CHANNEL) ||
((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) &&
(temp_p->chip != (AHC_AIC7880 | AHC_PCI))) )
{
...... select MMIO and does ioremap ....
...... if it fails select normal IO ....
}
#endif
that rejected my SCSI card from MMIO forcing normal IO resulting in machin
check. So I had to ignore this statement by #if !defined(__powerpc__) ...
#endif statement.
Does anyone know what is this restriction for?
After that aic7xxx.c properly detected two SCSI chips but entered in a
timeout/resetting loop:-( Apparently interrupts weren't fixed-up by
pcibios_fixup. So I scanned OF searching for correnct IRQ number and
found it at AAPL,interrupts field of P2P bridge. SCSI controllers didn't
have any AAPL,interrupts of course. It seems OF inserts AAPL,interrupts
only at the top node of the slot when it detects a card in the physical
slot. Therefore I had to change arch/ppc/kernel/prom.c as
--- prom.c.orig Sun Aug 29 00:22:21 1999
+++ prom.c Thu Sep 9 22:38:07 1999
@@ -915,8 +915,12 @@
}
ip = (int *) get_property(np, "AAPL,interrupts", &l);
- if (ip == 0)
- ip = (int *) get_property(np, "interrupts", &l);
+ if (ip == 0) {
+ if(get_property(np, "AAPL,slot-name", &l) != 0 && np->parent != 0)
+ ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
+ else
+ ip = (int *) get_property(np, "interrupts", &l);
+ }
if (ip != 0) {
np->intrs = (struct interrupt_info *) mem_start;
np->n_intrs = l / sizeof(int);
,and now aic7xxx.c is working fine for both SCSI channel.
I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific,
or SCSI card specific, or PowerMac OF nature. Any ideas?
Regards,
Ryuichi Oikawa
roikawa@rr.iij4u.or.jp
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PowerDomain 3940UWD
1999-09-09 17:14 PowerDomain 3940UWD Ryuichi Oikawa
@ 1999-09-09 18:14 ` Michel Lanners
1999-09-11 17:57 ` Ryuichi Oikawa
0 siblings, 1 reply; 5+ messages in thread
From: Michel Lanners @ 1999-09-09 18:14 UTC (permalink / raw)
To: roikawa; +Cc: linuxppc-dev
On 10 Sep, this message from Ryuichi Oikawa echoed through cyberspace:
> I've tried Adaptec PowerDomain 3094UWD, dual channel UW SCSI card
> with PCI-PCI bridge and two SCSI controllers under the bridge,
> and I noticed driver related and OF related problems.
>
> First I tried vger 2.2.12 kernel that caused machine check exception
> at first IO write transaction. I thought that this was normal because
> OF didn't properly set up P2P bridge's IO forwarding window.
> The real problem was this part(aic7xxx.c):
>
> #ifdef MMAPIO
> if ( !(temp_p->flags & AHC_MULTI_CHANNEL) ||
> ((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) &&
> (temp_p->chip != (AHC_AIC7880 | AHC_PCI))) )
> {
> ...... select MMIO and does ioremap ....
> ...... if it fails select normal IO ....
> }
> #endif
>
> that rejected my SCSI card from MMIO forcing normal IO resulting in machin
> check. So I had to ignore this statement by #if !defined(__powerpc__) ...
> #endif statement.
>
> Does anyone know what is this restriction for?
I could imagine that certain Adaptec SCSI chips use a regular PCI
memory region for their registers, while others use a PCI I/O region.
There are chances that the PCI I/O region is not enabled on your board,
and therefore accessing it results in a machine check.
Can you send me the output of lspci -vv, preferably once without the
aic7xxx driver in the kernel, and once with your fixes?
> After that aic7xxx.c properly detected two SCSI chips but entered in a
> timeout/resetting loop:-( Apparently interrupts weren't fixed-up by
> pcibios_fixup.
IRQs do get fixed, even on devices behind P2P bridges... iff OF did
assing IRQs, that is, as you found below.
> So I scanned OF searching for correnct IRQ number and
> found it at AAPL,interrupts field of P2P bridge. SCSI controllers didn't
> have any AAPL,interrupts of course. It seems OF inserts AAPL,interrupts
> only at the top node of the slot when it detects a card in the physical
> slot. Therefore I had to change arch/ppc/kernel/prom.c as
>
[snip'ed code]
Your fix looks OK to me; on PowerMacs, all PCI devices in any one slot
share the same interrupt, as the four PCI interrupt pins are OR'ed
together per slot.
> I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific,
> or SCSI card specific, or PowerMac OF nature. Any ideas?
Either OF-specific in general, or one of the many bugs in OF 1.0.5.
Anyway, as I said, your patch wouldn't break anything, even if OF did
assign IRQs already.
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PowerDomain 3940UWD
1999-09-09 18:14 ` Michel Lanners
@ 1999-09-11 17:57 ` Ryuichi Oikawa
1999-09-12 21:02 ` Michel Lanners
0 siblings, 1 reply; 5+ messages in thread
From: Ryuichi Oikawa @ 1999-09-11 17:57 UTC (permalink / raw)
To: mlan; +Cc: linuxppc-dev
From: Michel Lanners <mlan@cpu.lu>
Subject: Re: PowerDomain 3940UWD
> > #ifdef MMAPIO
> > if ( !(temp_p->flags & AHC_MULTI_CHANNEL) ||
> > ((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) &&
> > (temp_p->chip != (AHC_AIC7880 | AHC_PCI))) )
> > {
> > ...... select MMIO and does ioremap ....
> > ...... if it fails select normal IO ....
> > }
> > #endif
> I could imagine that certain Adaptec SCSI chips use a regular PCI
> memory region for their registers, while others use a PCI I/O region.
> There are chances that the PCI I/O region is not enabled on your board,
> and therefore accessing it results in a machine check.
Sorry, but my question was:
It looks like the author of this driver assumes adaptec chips with
temp_p->flags & AHC_MULTI_CHANNEL) ||
temp_p->chip == (AHC_AIC7870 | AHC_PCI) ||
temp_p->chip == (AHC_AIC7880 | AHC_PCI)
cannot support MMIO and it even skips the check for MMIO ability(of course,
check is done after enabling PCI_COMMAND_MEMORY bit), but PowerDomain3940UWD
(AHC_MULTI_CHANNEL && (AHC_AIC7880 | AHC_PCI)) does support MMIO and works fine,
so that I wonder if there are some broken cards or bioses with the above feature.
Is this patch below dangerous? I'd like to use MMIO on the PPC.
--- aic7xxx.c.orig Thu Sep 9 23:00:59 1999
+++ aic7xxx.c Thu Sep 9 23:03:06 1999
@@ -9660,9 +9660,11 @@
}
#ifdef MMAPIO
+#if !defined(__powerpc__)
if ( !(temp_p->flags & AHC_MULTI_CHANNEL) ||
((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) &&
(temp_p->chip != (AHC_AIC7880 | AHC_PCI))) )
+#endif
{
unsigned long page_offset, base;
> Can you send me the output of lspci -vv, preferably once without the
> aic7xxx driver in the kernel, and once with your fixes?
I'm very sorry, but I can't show the lspci output without the
aic7xxx driver because the SCSI card is now connected to the root
device.
I attached current lspci -vv output and /proc/device-tree list at the
end of this mail.
> IRQs do get fixed, even on devices behind P2P bridges... iff OF did
> assing IRQs, that is, as you found below.
Accoring to the list at the end, OF doesn't assign any IRQ to the adaptec
SCSI controller behind the bridge and IO forwarding to the CH.A device is
disable, though memory forwarding is enabled.
If disabled IO forwarding is a problem, I think the fixing is a
pcibios_fixupbus()'s job that is currently empty. It should be scanning
all PCI devices' base addresses behind the bridge and setting/expanding
IO/memory limits recursively. For that purpose, some methods will be
necessary that can judge properly whether the base address is right or
wrong because some broken logic board may write wrong values to the
base address registers. And I have no idea on that metohd...
> Your fix looks OK to me; on PowerMacs, all PCI devices in any one slot
> share the same interrupt, as the four PCI interrupt pins are OR'ed
> together per slot.
I see. Then assignig IRQ's to the only the top of the device node per
physical slot may be curious but reasonable, even if it is a non-interrupt
generating PCI-bridge.
> > I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific,
> > or SCSI card specific, or PowerMac OF nature. Any ideas?
>
> Either OF-specific in general, or one of the many bugs in OF 1.0.5.
> Anyway, as I said, your patch wouldn't break anything, even if OF did
> assign IRQs already.
Thank you, then would someone apply the patch to the kernel development
tree?
Regards,
Ryuichi Oikawa
roikawa@rr.iij4u.or.jp
Attached lists from here------
lspci -vv:
00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21050 (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 set, cache line size 08
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 80800000-808fffff
Prefetchable memory behind bridge: 80800000-807fffff
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
01:04.0 SCSI storage controller: Adaptec AIC-7882U
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 8 max, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 23
Region 0: I/O ports at <unassigned>
Region 1: Memory at 80800000 (32-bit, non-prefetchable)
01:05.0 SCSI storage controller: Adaptec AIC-7882U
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 8 max, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 23
Region 0: I/O ports at 1000
Region 1: Memory at 80801000 (32-bit, non-prefetchable)
and list of /proc/device-tree:
/proc/device-tree/bandit/pci-bridge:
name "pci-bridge"
vendor-id 00001011 (4113)
device-id 00000001
revision-id 00000002
class-code 00060400 (394240)
devsel-speed 00000001
fast-back-to-back
AAPL,interrupts 00000017 (23)
AAPL,slot-name "A1"
device_type "pci"
reg 00006800 00000000 00000000 00000000 00000000
#address-cells 00000003
#size-cells 00000002
ranges
bus-range 00000001 00000001
power-consumption 007270e0 007270e0
assigned-addresses
AAPL,address
driver-ist 000651a0 00000007 00000000 00000000 00000000 00000000
/proc/device-tree/bandit/pci-bridge/ADPT,3940UW:
name "ADPT,3940UW"
vendor-id 00009004 (36868)
device-id 00008278 (33400)
revision-id 00000000
class-code 00010000 (65536)
interrupts 00000001
min-grant 00000008
max-latency 00000008
devsel-speed 00000001
fast-back-to-back
AAPL,slot-name "A1"
fcode-rom-offset 00000000
device_type "scsi-2"
model "ADPT,942106-00"
compatible "ADPT,AIC-7880"
ADPT,fcode-date "04/07/99"
reg 00012000 00000000 00000000 00000000 00000000
02012014 00000000 00000000 00000000 00000100
02012030 00000000 00000000 00000000 00010000
power-consumption 00000000 00000000 007270e0 007270e0
00000000 00000000 007b98a0 007b98a0
assigned-addresses 82012030 00000000 80820000 00000000 00010000
82012014 00000000 80800000 00000000 00000100
AAPL,address 80820000 80800000
driver-ist 00065fb0 00000001 00000000 00000000 00000000 00000000
driver-descriptor 6d74656a 00000000 0b414450 542c3339
34305557 00000000 00000000 00000000
00000000 00000000 04108000 00000004
0d2e4164 61707465 63204348 494d0000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000001 73637369 00000000 01000000
driver-ptr 0006c590 (443792)
/proc/device-tree/bandit/pci-bridge/pci9004,8278:
name "pci9004,8278"
vendor-id 00009004 (36868)
device-id 00008278 (33400)
revision-id 00000000
class-code 00010000 (65536)
interrupts 00000001
min-grant 00000008
max-latency 00000008
devsel-speed 00000001
fast-back-to-back
AAPL,slot-name "A1"
reg 00012800 00000000 00000000 00000000 00000000
01012810 00000000 00000000 00000000 00000100
02012814 00000000 00000000 00000000 00001000
02012830 00000000 00000000 00000000 00010000
assigned-addresses 81012810 00000000 00001000 00000000 00000100
82012830 00000000 80810000 00000000 00010000
82012814 00000000 80801000 00000000 00001000
AAPL,address f2001000 80810000 80801000
driver-ist 00065fb0 00000002 00000000 00000000 00000000 00000000
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PowerDomain 3940UWD
1999-09-11 17:57 ` Ryuichi Oikawa
@ 1999-09-12 21:02 ` Michel Lanners
1999-09-18 19:07 ` Ryuichi Oikawa
0 siblings, 1 reply; 5+ messages in thread
From: Michel Lanners @ 1999-09-12 21:02 UTC (permalink / raw)
To: roikawa; +Cc: linuxppc-dev
On 12 Sep, this message from Ryuichi Oikawa echoed through cyberspace:
>> I could imagine that certain Adaptec SCSI chips use a regular PCI
>> memory region for their registers, while others use a PCI I/O region.
>> There are chances that the PCI I/O region is not enabled on your board,
>> and therefore accessing it results in a machine check.
> Sorry, but my question was:
> It looks like the author of this driver assumes adaptec chips with
> temp_p->flags & AHC_MULTI_CHANNEL) ||
> temp_p->chip == (AHC_AIC7870 | AHC_PCI) ||
> temp_p->chip == (AHC_AIC7880 | AHC_PCI)
> cannot support MMIO and it even skips the check for MMIO ability(of course,
> check is done after enabling PCI_COMMAND_MEMORY bit), but PowerDomain3940UWD
> (AHC_MULTI_CHANNEL && (AHC_AIC7880 | AHC_PCI)) does support MMIO and works fine,
> so that I wonder if there are some broken cards or bioses with the above feature.
Ahhh... then you should get in touch with the author of the driver, and
ask about his reasons for doing so.
> Is this patch below dangerous? I'd like to use MMIO on the PPC.
[patch snip'ed]
I'd qualify it dangerous, as it assumes that you can do MMIO on _any_
Adaptec chip in a PowerPC machine....
>> Can you send me the output of lspci -vv, preferably once without the
>> aic7xxx driver in the kernel, and once with your fixes?
> I attached current lspci -vv output and /proc/device-tree list at the
> end of this mail.
I'll comment below...
>> IRQs do get fixed, even on devices behind P2P bridges... iff OF did
>> assing IRQs, that is, as you found below.
> Accoring to the list at the end, OF doesn't assign any IRQ to the adaptec
> SCSI controller behind the bridge and IO forwarding to the CH.A device is
> disable, though memory forwarding is enabled.
Yeah, OF didn't assign any IO region to controller 1. That's weired....
I wonder whether OF was confused because of two identical PCI devices...
> If disabled IO forwarding is a problem, I think the fixing is a
> pcibios_fixupbus()'s job that is currently empty. It should be scanning
> all PCI devices' base addresses behind the bridge and setting/expanding
> IO/memory limits recursively. For that purpose, some methods will be
> necessary that can judge properly whether the base address is right or
> wrong because some broken logic board may write wrong values to the
> base address registers. And I have no idea on that metohd...
Right now, there are no methods implemented in Linux for assigning
resources to PCI devices _after_ startup; we're relying on the BIOS to
do that. If it does a bad job, then that has to be fixed in
pcibios_fixup(). However, there is work underway related to hotplug PCI
support, where dynamic resource assigment is a must.
pcibios_fixupbus() might be empty right now, but every machine type
under the PPC arch has it's own pcibios_fixup() routine; the one for
PowerMacs is in arch/ppc/kernel/pmac_pci.c. There is already some work
done there for fixing IRQ numbers; I'm workjing on adding even more
fixup. The IRQ problem you discovered is a good candidate for inclusion
as well.
>> Your fix looks OK to me; on PowerMacs, all PCI devices in any one slot
>> share the same interrupt, as the four PCI interrupt pins are OR'ed
>> together per slot.
> I see. Then assignig IRQ's to the only the top of the device node per
> physical slot may be curious but reasonable, even if it is a non-interrupt
> generating PCI-bridge.
>
>> > I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific,
>> > or SCSI card specific, or PowerMac OF nature. Any ideas?
>>
>> Either OF-specific in general, or one of the many bugs in OF 1.0.5.
>> Anyway, as I said, your patch wouldn't break anything, even if OF did
>> assign IRQs already.
> Thank you, then would someone apply the patch to the kernel development
> tree?
I'm only wondering about the more general case of a device without
IRQ... Will this patch make interrupts appear on those devices?
> lspci -vv:
> 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21050 (rev 02)
> I/O behind bridge: 00001000-00001fff
This IO wondow seems to be too small to accomodate both controllers....
I suppose OF assigned it too small?
> 01:04.0 SCSI storage controller: Adaptec AIC-7882U
> Region 0: I/O ports at <unassigned>
..... here OF didn't assign any IO region.
> 01:05.0 SCSI storage controller: Adaptec AIC-7882U
>
> and list of /proc/device-tree:
> /proc/device-tree/bandit/pci-bridge:
> name "pci-bridge"
>
> /proc/device-tree/bandit/pci-bridge/ADPT,3940UW:
> name "ADPT,3940UW"
>
> /proc/device-tree/bandit/pci-bridge/pci9004,8278:
> name "pci9004,8278"
That's the easy way to assign differing device names in OF... Although,
if I remeber right, the OF code onboard should generate differing names
by itslef, shouldn't it?
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PowerDomain 3940UWD
1999-09-12 21:02 ` Michel Lanners
@ 1999-09-18 19:07 ` Ryuichi Oikawa
0 siblings, 0 replies; 5+ messages in thread
From: Ryuichi Oikawa @ 1999-09-18 19:07 UTC (permalink / raw)
To: mlan; +Cc: linuxppc-dev
From: Michel Lanners <mlan@cpu.lu>
Subject: Re: PowerDomain 3940UWD
Sorry for very late response.
> > Is this patch below dangerous? I'd like to use MMIO on the PPC.
> [patch snip'ed]
>
> I'd qualify it dangerous, as it assumes that you can do MMIO on _any_
> Adaptec chip in a PowerPC machine....
More precisely it assumes that we can _check_ if MMIO is actually accessible
or not without causing machine check on any Adaptec card on a PPC, while the
original code assumes that we can do normal IO on any Adaptec card, which
made my card crashed. Which is more dangerous? Both? :-)
> Yeah, OF didn't assign any IO region to controller 1. That's weired....
> I wonder whether OF was confused because of two identical PCI devices...
$ hexdump /proc/bus/pci/01/04.0 (controller 1)
0000000 0490 7882 0700 8002 0000 0001 0820 0000
0000010 0100 0000 0000 8080 0000 0000 0000 0000
^^^^^^^^^
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 0000 8280 0000 0000 0000 0000 0001 0808
It looks like OF assined IO at 0x0000. Is '0' meaningless?
Of course IO forwarding is disabled as
$ hexdump /proc/bus/pci/00/0d.0
0000000 1110 0100 0700 8002 0200 0406 0820 0100
0000010 0000 0000 0000 0000 0001 0100 1010 8022
^^^^
0000020 8080 8080 8080 7080 0000 0000 0000 0000
0000030 0000 0000 0000 0000 0000 0000 0000 0400
> Right now, there are no methods implemented in Linux for assigning
> resources to PCI devices _after_ startup; we're relying on the BIOS to
> do that. If it does a bad job, then that has to be fixed in
> pcibios_fixup(). However, there is work underway related to hotplug PCI
> support, where dynamic resource assigment is a must.
That sounds intereting. Does that work like CardBus?
Can I access the code?
> pcibios_fixupbus() might be empty right now, but every machine type
> under the PPC arch has it's own pcibios_fixup() routine; the one for
> PowerMacs is in arch/ppc/kernel/pmac_pci.c. There is already some work
> done there for fixing IRQ numbers; I'm workjing on adding even more
> fixup. The IRQ problem you discovered is a good candidate for inclusion
> as well.
I never disagree that. You can do everything in _fixup(), but I wonder if
there is any job rest for _fixupbus()...
> I'm only wondering about the more general case of a device without
> IRQ... Will this patch make interrupts appear on those devices?
Unfortunately no in general, if
- the PCI card has more than one P2P bridge(what kind of card?)
- OF doesn't insert AAPL,slot-name property
- OF doesn't assign any IRQ to the card(how can we fix in this case??)
> > 01:04.0 SCSI storage controller: Adaptec AIC-7882U
> > Region 0: I/O ports at <unassigned>
>
> ..... here OF didn't assign any IO region.
0x0000?
> > and list of /proc/device-tree:
> > /proc/device-tree/bandit/pci-bridge:
> > name "pci-bridge"
> >
> > /proc/device-tree/bandit/pci-bridge/ADPT,3940UW:
> > name "ADPT,3940UW"
> >
> > /proc/device-tree/bandit/pci-bridge/pci9004,8278:
> > name "pci9004,8278"
>
> That's the easy way to assign differing device names in OF... Although,
> if I remeber right, the OF code onboard should generate differing names
> by itslef, shouldn't it?
OF seems to simply assign vendor,device as a name for nameless(?)
devie...
Regards,
Ryuichi Oikawa
roikawa@rr.iij4u.or.jp
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-09-18 19:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-09-09 17:14 PowerDomain 3940UWD Ryuichi Oikawa
1999-09-09 18:14 ` Michel Lanners
1999-09-11 17:57 ` Ryuichi Oikawa
1999-09-12 21:02 ` Michel Lanners
1999-09-18 19:07 ` Ryuichi Oikawa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).