Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Florent Nicart]

Hi Mike,

I ran into exactly the same issue on my Sun Ultra 60 with partman 
getting stuck at 33% when starting (before even accessing the partioning 
menu).


I found that the issue was related to the RAID detection, although I had 
no RAID and the only disk installed has been zeroed with dd.


Here is what I did :
- boot the installer in expert mode, where every step will be accessible 
in the installer menu,
- after the stage "load installation components" and before "disk 
partitionning",
- I opened a shell where I moved into /tmp the kernel module md.so and 
the command mdadm (localized with find),
- check that no process mdadm was running and no module md/mdraid was 
loaded,

- close the shell,
- carry on with the partitionning,
- there partman gets grumpy with a big red screen saying it cannot use 
the raid software, but not angry as it carries on straight to the disk 
partitioning.


Hope it helps.

I tried to find an option to tell the installer not to use RAID with no 
success (mdadm=false nor mdraid=false did not work).

If somebody knows a better/simpler way ...

Best regards,
Florent.

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Gregor Riepl]

> No, not that I remember, it looked like from the factory.
> 
> But I was also referring to something like [1]. And I also seem to
> remember similar issues with ALi/ULi chipsets (e.g. used in Blade 100
> and 150).
> 
> [1]: https://ata.wiki.kernel.org/index.php/Pata_cmd64x#Limitations

Found it in the source...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/pata_cmd64x.c#n386
It's similar for older CMD64x drivers (pre-libata).

And some ancient discussion here:
http://lkml.iu.edu/hypermail/linux/kernel/9811.3/0154.html

Now that's just sad. :(
MWDMA2 is limited to 16.7MB/s, half the speed of UDMA2.

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

> On Jun 22, 2020, at 8:17 AM, Gregor Riepl  wrote:
> 
>> @all:
>> Are there any users that had success with Promise based ATA controllers
>> on UltraSPARC?
> 
> As a matter of fact, I do. I had a software RAID running on 2 SATA disks
> on a Promise SATA300 TX4 controller and even built a custom mounting
> bracket for my old Ultra 10 to hold more than one disk.
> But, this was with Debian 4 (or thereabouts) and the sparc32 userland,
> and the boot disk was connected to the internal PATA controller.
> 
> Not sure if this still bears much relevance.
> 
>> @Mike:
>> I wonder if your problems could be an endianness issue in the Promise
>> drivers. In the end, I assume these were mostly used on x86. I'd expect
>> it to work with the onboard ATA controller of the Ultra 5 - at least it
>> worked for me when I tried an installation on my Ultra 10 and I believe
>> the hardware used in both machines is similar to identical. That it
>> works with OpenBSD for you could be due to their development process
>> which takes into account the specifics of many different architectures.
> 
> If there is any relevance to my older success story, the issue may have
> creeped in much later than kernel 2.6.18. It could also be a 32/64-bit
> issue, as the the Debian sparc kernel was 64-bit and the userland 32-bit
> back then (as far as I remember).


This has been solved. It was “hardware” related, sort of. I had turned of the 
EIDE board via  setenv pcib-probe-list  figuring that I was not using it and 
did not need it. (I also turned off the mach64 video card). Well curiously I 
think that prevents the system from being able to use DMA (I assume the IRQ 
never get allocated or something like that). Which causes these cards to be 
forced into PIO4 and not really work correctly with modern kernels. 

Here we see it correctly set up

[   14.063745] scsi host0: pata_pdc202xx_old
[   14.075370] scsi host1: pata_cmd64x
[   14.076299] scsi host2: pata_pdc202xx_old
[   14.076897] ata1: PATA max UDMA/100 cmd 0x1fe02000400 ctl 0x1fe02000408 
bmdma 0x1fe02000440 irq 15
[   14.076914] ata2: PATA max UDMA/100 cmd 0x1fe02000410 ctl 0x1fe02000418 
bmdma 0x1fe02000448 irq 15
[   14.087272] scsi host3: pata_cmd64x
[   14.088010] ata3: PATA max MWDMA2 cmd 0x1fe02c0 ctl 0x1fe02c8 bmdma 
0x1fe02c00020 irq 13
[   14.088026] ata4: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 bmdma 
0x1fe02c00028 irq 13
[   14.090801] pata_cmd64x: active 10 recovery 10 setup 3.
[   14.090821] pata_cmd64x: active 10 recovery 10 setup 3.
[   14.240097] ata1.00: ATA-9: OWC Mercury Electra 3G SSD, R0522A0, max UDMA/133
[   14.240118] ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 0/32)
[   14.264918] scsi 0:0:0:0: Direct-Access ATA  OWC Mercury Elec 2A0  
PQ: 0 ANSI: 5


The install is almost done, so after I’ve played around some bits I’ll post up 
a more complete success with details. [Feeling dumb for banging my head against 
that wall for so long but oh well.]

Thanks again for the input.

-Mike

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

> On Jun 22, 2020, at 11:48 AM, Frank Scheiner  wrote:
> 
> On 22.06.20 18:30, Gregor Riepl wrote:
>>> Rethinking that, I assume if an UltraSPARC machine boots from a CDROM
>>> drive attached to the built-in ATA controller and the installer later
>>> can find the disc to start the installation, it should also work with
>>> HDDs on that controller, though maybe not with UDMA speeds, but that was
>>> a common issue with some older chipsets IIRC. Not sure if these issues
>>> were with disc drives exclusively or also with disk drives.
>> 
>> My Ultra 10 has a CMD646 though, which supposedly supports up to UDMA2.
>> 
>> Dumb question: Did you check the cabling/jumper settings?
> 
> No, not that I remember, it looked like from the factory.
> 
> But I was also referring to something like [1]. And I also seem to
> remember similar issues with ALi/ULi chipsets (e.g. used in Blade 100
> and 150).
> 
> [1]: https://ata.wiki.kernel.org/index.php/Pata_cmd64x#Limitations
> 
> Cheers,
> Frank
> 


I should clarify that the experiments I’m running have the goal of using higher 
then UDMA2+ from a PCI connected ATA card that is BOOTABLE via openboot 3.31. 
So far I’ve got the bootable part several times over but the UDMA2+ is eluding 
me on sparc64.

1) As posted by Lloyd Parkes ages ago 
https://www.netbsd.org/ports/sparc64/faq.html#pci-cards 
 you can teach 
OpenBoot to treat some PCI IDE cards the same as the internal IDE controller. 
This lets you boot. I can post a longer explanation if you need to see 
specifically how this works. You can quickly tell if a card is worth trying if 
your “show-devs” at openboot has some weird path into the /dev tree. When you 
add to the nvram you basically fix that so it knows it’s an IDE controller.

2) I have not been able to install Debian Sparc64 9 or 10 using this process 
which is what this thread was looking for answers to, but I have managed to get 
OpenBSD 6.2+ to work fine, EXCEPT that I get UDMA2 / PIO4 out of it. I think I 
get about 21MB/sec using repeated DD if/of tests.

What I really want to see is 100MB/sec. I have SCSI PCI cards and all that, 
this is just really an itch I have to scratch. So I take a run at it every 6-8 
months.

-Mike

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 18:30, Gregor Riepl wrote:

Rethinking that, I assume if an UltraSPARC machine boots from a CDROM
drive attached to the built-in ATA controller and the installer later
can find the disc to start the installation, it should also work with
HDDs on that controller, though maybe not with UDMA speeds, but that was
a common issue with some older chipsets IIRC. Not sure if these issues
were with disc drives exclusively or also with disk drives.


My Ultra 10 has a CMD646 though, which supposedly supports up to UDMA2.

Dumb question: Did you check the cabling/jumper settings?


No, not that I remember, it looked like from the factory.

But I was also referring to something like [1]. And I also seem to
remember similar issues with ALi/ULi chipsets (e.g. used in Blade 100
and 150).

[1]: https://ata.wiki.kernel.org/index.php/Pata_cmd64x#Limitations

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Gregor Riepl]

> Rethinking that, I assume if an UltraSPARC machine boots from a CDROM
> drive attached to the built-in ATA controller and the installer later
> can find the disc to start the installation, it should also work with
> HDDs on that controller, though maybe not with UDMA speeds, but that was
> a common issue with some older chipsets IIRC. Not sure if these issues
> were with disc drives exclusively or also with disk drives.

My Ultra 10 has a CMD646 though, which supposedly supports up to UDMA2.

Dumb question: Did you check the cabling/jumper settings?

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 17:37, Connor McLaughlan wrote:

Can you by any chance tell me how i could obtain a list of all PCI
cards that are possibly supported  and might work on debian sparc?


Sorry, no idea. I avoid disks in my machines wherever possible.

Even the list from OpenBSD ([1]) for PCI IDE Controllers is rather
short. I assume it's like they say there also on Debian: "Other PCI IDE
adapters may work, but are untested."

[1]: http://www.openbsd.org/sparc64.html

The same might hold true for other removable PCI hardware.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Anatoly Pugachev]

On Mon, Jun 22, 2020 at 6:37 PM Connor McLaughlan  wrote:
>
> Can you by any chance tell me how i could obtain a list of all PCI
> cards that are possibly supported  and might work on debian sparc?

Probably most PCI cards supported by kernel ?

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Connor McLaughlan]

Can you by any chance tell me how i could obtain a list of all PCI
cards that are possibly supported  and might work on debian sparc?

Regards,
Connor

On Mon, Jun 22, 2020 at 5:33 PM Frank Scheiner  wrote:
>
> On 22.06.20 17:17, Gregor Riepl wrote:
> >> @all:
> >> Are there any users that had success with Promise based ATA controllers
> >> on UltraSPARC?
> >
> > As a matter of fact, I do. I had a software RAID running on 2 SATA disks
> > on a Promise SATA300 TX4 controller and even built a custom mounting
> > bracket for my old Ultra 10 to hold more than one disk.
> > But, this was with Debian 4 (or thereabouts) and the sparc32 userland,
> > and the boot disk was connected to the internal PATA controller.
> >
> > Not sure if this still bears much relevance.
>
> Well, so the driver was at least working somewhere in the past. OTOH
> you're speaking about SATA, so most likely this was with another driver.
> Looking at [1] the Promise SATA300 TX4 looks like a "real" SATA
> controller not like older ones that were actually ATA controllers and
> used some adapter chips. Maybe things also look differently with SATA.
> But interesting point anyhow - SATA RAID on Ultra 10. :-)
>
> [1]: https://www.phoronix.com/scan.php?page=article=815=1
>
> >
> >> @Mike:
> >> I wonder if your problems could be an endianness issue in the Promise
> >> drivers. In the end, I assume these were mostly used on x86. I'd expect
> >> it to work with the onboard ATA controller of the Ultra 5 - at least it
> >> worked for me when I tried an installation on my Ultra 10 and I believe
> >> the hardware used in both machines is similar to identical. That it
> >> works with OpenBSD for you could be due to their development process
> >> which takes into account the specifics of many different architectures.
> >
> > If there is any relevance to my older success story, the issue may have
> > creeped in much later than kernel 2.6.18. It could also be a 32/64-bit
> > issue, as the the Debian sparc kernel was 64-bit and the userland 32-bit
> > back then (as far as I remember).
>
> Yeah, but the drivers don't depend on the userland, or do they? Maybe
> the specific Promise driver for Mike's controller just broke some time
> ago or was broken on UltraSPARC ever since.
>
> Cheers,
> Frank
>

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 17:17, Gregor Riepl wrote:

@all:
Are there any users that had success with Promise based ATA controllers
on UltraSPARC?


As a matter of fact, I do. I had a software RAID running on 2 SATA disks
on a Promise SATA300 TX4 controller and even built a custom mounting
bracket for my old Ultra 10 to hold more than one disk.
But, this was with Debian 4 (or thereabouts) and the sparc32 userland,
and the boot disk was connected to the internal PATA controller.

Not sure if this still bears much relevance.


Well, so the driver was at least working somewhere in the past. OTOH
you're speaking about SATA, so most likely this was with another driver.
Looking at [1] the Promise SATA300 TX4 looks like a "real" SATA
controller not like older ones that were actually ATA controllers and
used some adapter chips. Maybe things also look differently with SATA.
But interesting point anyhow - SATA RAID on Ultra 10. :-)

[1]: https://www.phoronix.com/scan.php?page=article=815=1




@Mike:
I wonder if your problems could be an endianness issue in the Promise
drivers. In the end, I assume these were mostly used on x86. I'd expect
it to work with the onboard ATA controller of the Ultra 5 - at least it
worked for me when I tried an installation on my Ultra 10 and I believe
the hardware used in both machines is similar to identical. That it
works with OpenBSD for you could be due to their development process
which takes into account the specifics of many different architectures.


If there is any relevance to my older success story, the issue may have
creeped in much later than kernel 2.6.18. It could also be a 32/64-bit
issue, as the the Debian sparc kernel was 64-bit and the userland 32-bit
back then (as far as I remember).


Yeah, but the drivers don't depend on the userland, or do they? Maybe
the specific Promise driver for Mike's controller just broke some time
ago or was broken on UltraSPARC ever since.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 16:58, Mike Tremaine wrote:

[...] Worth checking, I’ll have look at the drive code and see if I
can make sense of it. A follow up question might be does anyone have
ATA based install other than the Ultra 5/10 running? Example does
anyone have SunFire v100 running debian 9 or 10? I have one that’s
offline in a rack (Solaris 10 when it was powered down several years
back), I might be able to get my hands on it for testing.


Years ago I had Debian - I believe 5 - running from disk on a Blade 100
using the built-in ATA controller. Later I only ran it diskless with
Debian unstable IIRC, same for my V100.

Rethinking that, I assume if an UltraSPARC machine boots from a CDROM
drive attached to the built-in ATA controller and the installer later
can find the disc to start the installation, it should also work with
HDDs on that controller, though maybe not with UDMA speeds, but that was
a common issue with some older chipsets IIRC. Not sure if these issues
were with disc drives exclusively or also with disk drives.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Gregor Riepl]

> @all:
> Are there any users that had success with Promise based ATA controllers
> on UltraSPARC?

As a matter of fact, I do. I had a software RAID running on 2 SATA disks
on a Promise SATA300 TX4 controller and even built a custom mounting
bracket for my old Ultra 10 to hold more than one disk.
But, this was with Debian 4 (or thereabouts) and the sparc32 userland,
and the boot disk was connected to the internal PATA controller.

Not sure if this still bears much relevance.

> @Mike:
> I wonder if your problems could be an endianness issue in the Promise
> drivers. In the end, I assume these were mostly used on x86. I'd expect
> it to work with the onboard ATA controller of the Ultra 5 - at least it
> worked for me when I tried an installation on my Ultra 10 and I believe
> the hardware used in both machines is similar to identical. That it
> works with OpenBSD for you could be due to their development process
> which takes into account the specifics of many different architectures.

If there is any relevance to my older success story, the issue may have
creeped in much later than kernel 2.6.18. It could also be a 32/64-bit
issue, as the the Debian sparc kernel was 64-bit and the userland 32-bit
back then (as far as I remember).

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

> On Jun 21, 2020, at 11:09 PM, Frank Scheiner  wrote:
> 
> Hi Mike, all on the list,
> 
> On 22.06.20 02:06, Mike Tremaine wrote:
>> [...]
 Can you try replacing the IDE cable or try a different disk?
 
 Adrian
 
>>> [...]
>> Sadly no good outcome. Different cables made no difference, I tried a
>> PDC20269 Card (which uses pata_pdc2027x
>> )
>> and in that case I can not see the disk nor the cdrom once the kernel
>> has loaded. (Which is consistent with Debian 9 SILO installer on that card)
>> That is I can boot the cd and then when it comes to the stage of loading
>> from the media it can not be found. asmod shows the pdc2027x drive is
>> loaded and lspci shows the card but no devices are on it.
>> The PDC20267 (Promise ATA 100 using pata_pdc202xx_old) is the original
>> card I was working with today and it can’t make the filesystem. [Opps
>> posted]
>> I went ahead and tried OpenBSD6.7 on this new disk to see if it works
>> and it does. So I’m right back where I was before I began this exercise.
>> I need to find a HighPoint HPT366 the non-raid kind of card to see if it
>> can been used. I know I tried at least one SILxxx and it was not useable
>> by OpenBoot.  I’ll keep thinking about ways around this. I wonder if the
>> FCode linking I do to the card somehow limits the DMA mode to match the
>> onboard limit. It’s kind of a blackbox to me. But I thought once the
>> kernels take over they would sort it out.
> 
> @all:
> Are there any users that had success with Promise based ATA controllers
> on UltraSPARC?
> 
> @Mike:
> I wonder if your problems could be an endianness issue in the Promise
> drivers. In the end, I assume these were mostly used on x86. I'd expect
> it to work with the onboard ATA controller of the Ultra 5 - at least it
> worked for me when I tried an installation on my Ultra 10 and I believe
> the hardware used in both machines is similar to identical. That it
> works with OpenBSD for you could be due to their development process
> which takes into account the specifics of many different architectures.
> 
> Cheers,
> Frank
> 


Worth checking, I’ll have look at the drive code and see if I can make sense of 
it. A follow up question might be does anyone have ATA based install other than 
the Ultra 5/10 running? Example does anyone have SunFire v100 running debian 9 
or 10? I have one that’s offline in a rack (Solaris 10 when it was powered down 
several years back), I might be able to get my hands on it for testing.

-Mike

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

Hi Mike, all on the list,

On 22.06.20 02:06, Mike Tremaine wrote:

[...]

Can you try replacing the IDE cable or try a different disk?

Adrian


[...]

Sadly no good outcome. Different cables made no difference, I tried a
PDC20269 Card (which uses pata_pdc2027x
)
and in that case I can not see the disk nor the cdrom once the kernel
has loaded. (Which is consistent with Debian 9 SILO installer on that card)
That is I can boot the cd and then when it comes to the stage of loading
from the media it can not be found. asmod shows the pdc2027x drive is
loaded and lspci shows the card but no devices are on it.
The PDC20267 (Promise ATA 100 using pata_pdc202xx_old) is the original
card I was working with today and it can’t make the filesystem. [Opps
posted]
I went ahead and tried OpenBSD6.7 on this new disk to see if it works
and it does. So I’m right back where I was before I began this exercise.
I need to find a HighPoint HPT366 the non-raid kind of card to see if it
can been used. I know I tried at least one SILxxx and it was not useable
by OpenBoot.  I’ll keep thinking about ways around this. I wonder if the
FCode linking I do to the card somehow limits the DMA mode to match the
onboard limit. It’s kind of a blackbox to me. But I thought once the
kernels take over they would sort it out.


@all:
Are there any users that had success with Promise based ATA controllers
on UltraSPARC?

@Mike:
I wonder if your problems could be an endianness issue in the Promise
drivers. In the end, I assume these were mostly used on x86. I'd expect
it to work with the onboard ATA controller of the Ultra 5 - at least it
worked for me when I tried an installation on my Ultra 10 and I believe
the hardware used in both machines is similar to identical. That it
works with OpenBSD for you could be due to their development process
which takes into account the specifics of many different architectures.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

> On Jun 21, 2020, at 11:44 AM, Mike Tremaine  wrote:
> 
> 
> 
>> On Jun 21, 2020, at 11:38 AM, John Paul Adrian Glaubitz 
>>  wrote:
>> 
>> On 6/21/20 8:33 PM, Mike Tremaine wrote:
>>> And the oops was in the log I just couldn’t see because of the local 
>>> console 640x480 but via ssh I can
>>> 
>>> Jun 21 18:30:16 partman: Found a sun partition table in /dev/sda1
>>> Jun 21 18:30:16 kernel: [ 1184.765065] Unable to handle kernel NULL pointer 
>>> dereference
>>> Jun 21 18:30:16 kernel: [ 1184.765110] tsk->{mm,active_mm}->context = 
>>> 0e99
>>> Jun 21 18:30:16 kernel: [ 1184.765123] tsk->{mm,active_mm}->pgd = 
>>> f8001b64c000
>>> Jun 21 18:30:16 kernel: [ 1184.765136]   \|/  \|/
>>> Jun 21 18:30:16 kernel: [ 1184.765136]   "@'/ .. \`@"
>>> Jun 21 18:30:16 kernel: [ 1184.765136]   /_| \__/ |_\
>>> Jun 21 18:30:16 kernel: [ 1184.765136]  \__U_/
>>> Jun 21 18:30:16 kernel: [ 1184.765150] kworker/0:1H(103): Oops [#1]
>>> 
>> 
>> Can you try replacing the IDE cable or try a different disk?
>> 
>> Adrian
>> 
> 
> Yes, I’ll try hardware combos. This is basically an attempt to get a PCI ATA 
> card working end to end, from Openboot to OS, without touching the original 
> IDE. I have this card working with openbsd and the Openboot instructions I 
> posted a few years back but I could not get the drives seen by Debian 9 
> installer, was hoping to get further this time, which I have. I’ll post back 
> if I have more details.
> 
> Thanks for the help.
> 
> -Mike 

Sadly no good outcome. Different cables made no difference, I tried a PDC20269 
Card (which uses pata_pdc2027x 
) 
and in that case I can not see the disk nor the cdrom once the kernel has 
loaded. (Which is consistent with Debian 9 SILO installer on that card)
That is I can boot the cd and then when it comes to the stage of loading from 
the media it can not be found. asmod shows the pdc2027x drive is loaded and 
lspci shows the card but no devices are on it. 
The PDC20267 (Promise ATA 100 using pata_pdc202xx_old) is the original card I 
was working with today and it can’t make the filesystem. [Opps posted]
I went ahead and tried OpenBSD6.7 on this new disk to see if it works and it 
does. So I’m right back where I was before I began this exercise. I need to 
find a HighPoint HPT366 the non-raid kind of card to see if it can been used. I 
know I tried at least one SILxxx and it was not useable by OpenBoot.  I’ll keep 
thinking about ways around this. I wonder if the FCode linking I do to the card 
somehow limits the DMA mode to match the onboard limit. It’s kind of a blackbox 
to me. But I thought once the kernels take over they would sort it out.

-Mike

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

> On Jun 21, 2020, at 11:38 AM, John Paul Adrian Glaubitz 
>  wrote:
> 
> On 6/21/20 8:33 PM, Mike Tremaine wrote:
>> And the oops was in the log I just couldn’t see because of the local console 
>> 640x480 but via ssh I can
>> 
>> Jun 21 18:30:16 partman: Found a sun partition table in /dev/sda1
>> Jun 21 18:30:16 kernel: [ 1184.765065] Unable to handle kernel NULL pointer 
>> dereference
>> Jun 21 18:30:16 kernel: [ 1184.765110] tsk->{mm,active_mm}->context = 
>> 0e99
>> Jun 21 18:30:16 kernel: [ 1184.765123] tsk->{mm,active_mm}->pgd = 
>> f8001b64c000
>> Jun 21 18:30:16 kernel: [ 1184.765136]   \|/  \|/
>> Jun 21 18:30:16 kernel: [ 1184.765136]   "@'/ .. \`@"
>> Jun 21 18:30:16 kernel: [ 1184.765136]   /_| \__/ |_\
>> Jun 21 18:30:16 kernel: [ 1184.765136]  \__U_/
>> Jun 21 18:30:16 kernel: [ 1184.765150] kworker/0:1H(103): Oops [#1]
>> 
> 
> Can you try replacing the IDE cable or try a different disk?
> 
> Adrian
> 

Yes, I’ll try hardware combos. This is basically an attempt to get a PCI ATA 
card working end to end, from Openboot to OS, without touching the original 
IDE. I have this card working with openbsd and the Openboot instructions I 
posted a few years back but I could not get the drives seen by Debian 9 
installer, was hoping to get further this time, which I have. I’ll post back if 
I have more details.

Thanks for the help.

-Mike 

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[John Paul Adrian Glaubitz]

On 6/21/20 8:33 PM, Mike Tremaine wrote:
> And the oops was in the log I just couldn’t see because of the local console 
> 640x480 but via ssh I can
> 
> Jun 21 18:30:16 partman: Found a sun partition table in /dev/sda1
> Jun 21 18:30:16 kernel: [ 1184.765065] Unable to handle kernel NULL pointer 
> dereference
> Jun 21 18:30:16 kernel: [ 1184.765110] tsk->{mm,active_mm}->context = 
> 0e99
> Jun 21 18:30:16 kernel: [ 1184.765123] tsk->{mm,active_mm}->pgd = 
> f8001b64c000
> Jun 21 18:30:16 kernel: [ 1184.765136]   \|/  \|/
> Jun 21 18:30:16 kernel: [ 1184.765136]   "@'/ .. \`@"
> Jun 21 18:30:16 kernel: [ 1184.765136]   /_| \__/ |_\
> Jun 21 18:30:16 kernel: [ 1184.765136]  \__U_/
> Jun 21 18:30:16 kernel: [ 1184.765150] kworker/0:1H(103): Oops [#1]
> Jun 21 18:30:16 kernel: [ 1184.765178] CPU: 0 PID: 103 Comm: kworker/0:1H 
> Tainted: GE 5.6.0-2-sparc64 #1 Debian 5.6.14-1
> Jun 21 18:30:16 kernel: [ 1184.765221] Workqueue: kblockd blk_mq_run_work_fn
> Jun 21 18:30:16 kernel: [ 1184.765243] TSTATE: 009980e01606 TPC: 
> 1016d20c TNPC: 1016d210 Y: Tainted: GE
> Jun 21 18:30:16 kernel: [ 1184.765386] TPC:  [libata]>
> Jun 21 18:30:16 kernel: [ 1184.765399] g0: 004208b0 g1: 
>  g2: c1dc6000 g3: 00c1dc600060dcc1
> Jun 21 18:30:16 kernel: [ 1184.765409] g4: f8001abba9e0 g5: 
> 7f2bb706 g6: f8001aa4 g7: 0002
> Jun 21 18:30:16 kernel: [ 1184.765421] o0: f8001a8e85b0 o1: 
> f8001a1c7000 o2: f8001a287720 o3: f8001aa43618
> Jun 21 18:30:16 kernel: [ 1184.765431] o4:  o5: 
> dc00 sp: f8001aa42d71 ret_pc: 0200
> Jun 21 18:30:16 kernel: [ 1184.765443] RPC: <0x200>
> Jun 21 18:30:16 kernel: [ 1184.765455] l0: 0001 l1: 
>  l2: 00ff l3: 
> Jun 21 18:30:16 kernel: [ 1184.765466] l4:  l5: 
> 0001 l6: 0200 l7: 0200
> Jun 21 18:30:16 kernel: [ 1184.765477] i0: f8001a32c130 i1: 
>  i2:  i3: ff00
> Jun 21 18:30:16 kernel: [ 1184.765487] i4: 0200 i5: 
>  i6: f8001aa42e21 i7: 1015738c
> Jun 21 18:30:16 kernel: [ 1184.76] I7: 
> Jun 21 18:30:16 kernel: [ 1184.765561] Call Trace:
> Jun 21 18:30:16 kernel: [ 1184.765629]  [1015738c] 
> ata_qc_issue+0x14c/0x3a0 [libata]
> Jun 21 18:30:16 kernel: [ 1184.765696]  [1015f01c] 
> ata_scsi_translate+0xbc/0x1c0 [libata]
> Jun 21 18:30:16 kernel: [ 1184.765763]  [10163a78] 
> ata_scsi_queuecmd+0xb8/0x300 [libata]
> Jun 21 18:30:16 kernel: [ 1184.765880]  [100134a8] 
> scsi_queue_rq+0x548/0xa20 [scsi_mod]
> Jun 21 18:30:16 kernel: [ 1184.765903]  [00799b10] 
> blk_mq_dispatch_rq_list+0x370/0x580
> Jun 21 18:30:16 kernel: [ 1184.765926]  [0079e900] 
> blk_mq_do_dispatch_sched+0x60/0x120
> Jun 21 18:30:16 kernel: [ 1184.765944]  [0079f08c] 
> blk_mq_sched_dispatch_requests+0xec/0x1a0
> Jun 21 18:30:16 kernel: [ 1184.765959]  [007973f4] 
> __blk_mq_run_hw_queue+0x54/0x1a0
> Jun 21 18:30:16 kernel: [ 1184.765974]  [00797684] 
> blk_mq_run_work_fn+0x24/0x40
> Jun 21 18:30:16 kernel: [ 1184.766000]  [00482ef4] 
> process_one_work+0x194/0x480
> Jun 21 18:30:16 kernel: [ 1184.766016]  [00483324] 
> worker_thread+0x144/0x540
> Jun 21 18:30:16 kernel: [ 1184.766041]  [0048917c] kthread+0xdc/0x120
> Jun 21 18:30:16 kernel: [ 1184.766068]  [00405fa4] 
> ret_from_fork+0x1c/0x2c
> Jun 21 18:30:16 kernel: [ 1184.766079]  [] 0x0
> Jun 21 18:30:16 kernel: [ 1184.766086] Disabling lock debugging due to kernel 
> taint
> Jun 21 18:30:16 kernel: [ 1184.766168] Caller[1015738c]: 
> ata_qc_issue+0x14c/0x3a0 [libata]
> Jun 21 18:30:16 kernel: [ 1184.766235] Caller[1015f01c]: 
> ata_scsi_translate+0xbc/0x1c0 [libata]
> Jun 21 18:30:16 kernel: [ 1184.766302] Caller[10163a78]: 
> ata_scsi_queuecmd+0xb8/0x300 [libata]
> Jun 21 18:30:16 kernel: [ 1184.766374] Caller[100134a8]: 
> scsi_queue_rq+0x548/0xa20 [scsi_mod]
> Jun 21 18:30:16 kernel: [ 1184.766394] Caller[00799b10]: 
> blk_mq_dispatch_rq_list+0x370/0x580
> Jun 21 18:30:16 kernel: [ 1184.766413] Caller[0079e900]: 
> blk_mq_do_dispatch_sched+0x60/0x120
> Jun 21 18:30:16 kernel: [ 1184.766431] Caller[0079f08c]: 
> blk_mq_sched_dispatch_requests+0xec/0x1a0
> Jun 21 18:30:16 kernel: [ 1184.766447] Caller[007973f4]: 
> __blk_mq_run_hw_queue+0x54/0x1a0
> Jun 21 18:30:16 kernel: [ 1184.766462] Caller[00797684]: 
> blk_mq_run_work_fn+0x24/0x40
> Jun 21 18:30:16 kernel: [ 1184.766480] Caller[00482ef4]: 
> process_one_work+0x194/0x480
> Jun 21 18:30:16 kernel: [ 1184.766496] Caller[00483324]: 
> worker_thread+0x144/0x540

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

> On Jun 21, 2020, at 11:02 AM, John Paul Adrian Glaubitz 
>  wrote:
> 
> On 6/21/20 7:25 PM, Frank Scheiner wrote: > If it's the same issue as with my 
> Ultra 10, you (1) either have to wait
>> longer or (2) have to remove your floppy disk drive from the controller
>> before doing an installation. #2 definitely saves some time.
> 
> I agree. This sounds like a hardware issue.
> 
> I would check the syslog console during installation on one of the other 
> virtual
> consoles and see if mkfs.e2fs prints any error messages.
> 
> The installer can hang when mkfs.e2fs produces an unexpected error message, so
> it's always wise to look at the installation log.
> 
> Adrian
> 

And the oops was in the log I just couldn’t see because of the local console 
640x480 but via ssh I can

Jun 21 18:30:16 partman: Found a sun partition table in /dev/sda1
Jun 21 18:30:16 kernel: [ 1184.765065] Unable to handle kernel NULL pointer 
dereference
Jun 21 18:30:16 kernel: [ 1184.765110] tsk->{mm,active_mm}->context = 
0e99
Jun 21 18:30:16 kernel: [ 1184.765123] tsk->{mm,active_mm}->pgd = 
f8001b64c000
Jun 21 18:30:16 kernel: [ 1184.765136]   \|/  \|/
Jun 21 18:30:16 kernel: [ 1184.765136]   "@'/ .. \`@"
Jun 21 18:30:16 kernel: [ 1184.765136]   /_| \__/ |_\
Jun 21 18:30:16 kernel: [ 1184.765136]  \__U_/
Jun 21 18:30:16 kernel: [ 1184.765150] kworker/0:1H(103): Oops [#1]
Jun 21 18:30:16 kernel: [ 1184.765178] CPU: 0 PID: 103 Comm: kworker/0:1H 
Tainted: GE 5.6.0-2-sparc64 #1 Debian 5.6.14-1
Jun 21 18:30:16 kernel: [ 1184.765221] Workqueue: kblockd blk_mq_run_work_fn
Jun 21 18:30:16 kernel: [ 1184.765243] TSTATE: 009980e01606 TPC: 
1016d20c TNPC: 1016d210 Y: Tainted: GE
Jun 21 18:30:16 kernel: [ 1184.765386] TPC: 
Jun 21 18:30:16 kernel: [ 1184.765399] g0: 004208b0 g1: 
 g2: c1dc6000 g3: 00c1dc600060dcc1
Jun 21 18:30:16 kernel: [ 1184.765409] g4: f8001abba9e0 g5: 
7f2bb706 g6: f8001aa4 g7: 0002
Jun 21 18:30:16 kernel: [ 1184.765421] o0: f8001a8e85b0 o1: 
f8001a1c7000 o2: f8001a287720 o3: f8001aa43618
Jun 21 18:30:16 kernel: [ 1184.765431] o4:  o5: 
dc00 sp: f8001aa42d71 ret_pc: 0200
Jun 21 18:30:16 kernel: [ 1184.765443] RPC: <0x200>
Jun 21 18:30:16 kernel: [ 1184.765455] l0: 0001 l1: 
 l2: 00ff l3: 
Jun 21 18:30:16 kernel: [ 1184.765466] l4:  l5: 
0001 l6: 0200 l7: 0200
Jun 21 18:30:16 kernel: [ 1184.765477] i0: f8001a32c130 i1: 
 i2:  i3: ff00
Jun 21 18:30:16 kernel: [ 1184.765487] i4: 0200 i5: 
 i6: f8001aa42e21 i7: 1015738c
Jun 21 18:30:16 kernel: [ 1184.76] I7: 
Jun 21 18:30:16 kernel: [ 1184.765561] Call Trace:
Jun 21 18:30:16 kernel: [ 1184.765629]  [1015738c] 
ata_qc_issue+0x14c/0x3a0 [libata]
Jun 21 18:30:16 kernel: [ 1184.765696]  [1015f01c] 
ata_scsi_translate+0xbc/0x1c0 [libata]
Jun 21 18:30:16 kernel: [ 1184.765763]  [10163a78] 
ata_scsi_queuecmd+0xb8/0x300 [libata]
Jun 21 18:30:16 kernel: [ 1184.765880]  [100134a8] 
scsi_queue_rq+0x548/0xa20 [scsi_mod]
Jun 21 18:30:16 kernel: [ 1184.765903]  [00799b10] 
blk_mq_dispatch_rq_list+0x370/0x580
Jun 21 18:30:16 kernel: [ 1184.765926]  [0079e900] 
blk_mq_do_dispatch_sched+0x60/0x120
Jun 21 18:30:16 kernel: [ 1184.765944]  [0079f08c] 
blk_mq_sched_dispatch_requests+0xec/0x1a0
Jun 21 18:30:16 kernel: [ 1184.765959]  [007973f4] 
__blk_mq_run_hw_queue+0x54/0x1a0
Jun 21 18:30:16 kernel: [ 1184.765974]  [00797684] 
blk_mq_run_work_fn+0x24/0x40
Jun 21 18:30:16 kernel: [ 1184.766000]  [00482ef4] 
process_one_work+0x194/0x480
Jun 21 18:30:16 kernel: [ 1184.766016]  [00483324] 
worker_thread+0x144/0x540
Jun 21 18:30:16 kernel: [ 1184.766041]  [0048917c] kthread+0xdc/0x120
Jun 21 18:30:16 kernel: [ 1184.766068]  [00405fa4] 
ret_from_fork+0x1c/0x2c
Jun 21 18:30:16 kernel: [ 1184.766079]  [] 0x0
Jun 21 18:30:16 kernel: [ 1184.766086] Disabling lock debugging due to kernel 
taint
Jun 21 18:30:16 kernel: [ 1184.766168] Caller[1015738c]: 
ata_qc_issue+0x14c/0x3a0 [libata]
Jun 21 18:30:16 kernel: [ 1184.766235] Caller[1015f01c]: 
ata_scsi_translate+0xbc/0x1c0 [libata]
Jun 21 18:30:16 kernel: [ 1184.766302] Caller[10163a78]: 
ata_scsi_queuecmd+0xb8/0x300 [libata]
Jun 21 18:30:16 kernel: [ 1184.766374] Caller[100134a8]: 
scsi_queue_rq+0x548/0xa20 [scsi_mod]
Jun 21 18:30:16 kernel: [ 1184.766394] Caller[00799b10]: 
blk_mq_dispatch_rq_list+0x370/0x580
Jun 21 18:30:16 kernel: [ 1184.766413] Caller[0079e900]: 
blk_mq_do_dispatch_sched+0x60/0x120
Jun 21 18:30:16 kernel: [ 

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[John Paul Adrian Glaubitz]

On 6/21/20 7:25 PM, Frank Scheiner wrote: > If it's the same issue as with my 
Ultra 10, you (1) either have to wait
> longer or (2) have to remove your floppy disk drive from the controller
> before doing an installation. #2 definitely saves some time.

I agree. This sounds like a hardware issue.

I would check the syslog console during installation on one of the other virtual
consoles and see if mkfs.e2fs prints any error messages.

The installer can hang when mkfs.e2fs produces an unexpected error message, so
it's always wise to look at the installation log.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

> On Jun 21, 2020, at 10:25 AM, Frank Scheiner  wrote:
> 
> On 21.06.20 19:21, Mike Tremaine wrote:
>> I spent a few hours trying different things on this but no luck.
>> 
>> Hardware: Sun Ultra 5 - 333mhz / 512MB  - Promise 100 PCI card as IDE
>> interface..
>> 
>> Install Image:2020-05-30/debian-10.0.0-sparc64-NETINST-1.iso
>> 
>> Boots CDROM and finds disks no problem.
>> 
>> Issue is after the partitioning is done and the installer runs mkfs.ext2
>> -F /dev/sda1 it hangs and the process goes Defunct. I’ve tried many
>> different layouts with/without LVM, with/without /home always the same
>> spot 33% ….
> 
> If it's the same issue as with my Ultra 10, you (1) either have to wait
> longer or (2) have to remove your floppy disk drive from the controller
> before doing an installation. #2 definitely saves some time.
> 
> Cheers,
> Frank
> 

I unplugged the FD cable from the floppy drive, rebooted and tried again…It’s 
doing the same thing, I’ll let sit for good while and see if can get passed 
unless I misunderstood.

-Mike

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 21.06.20 19:21, Mike Tremaine wrote:

I spent a few hours trying different things on this but no luck.

Hardware: Sun Ultra 5 - 333mhz / 512MB  - Promise 100 PCI card as IDE
interface..

Install Image:2020-05-30/debian-10.0.0-sparc64-NETINST-1.iso

Boots CDROM and finds disks no problem.

Issue is after the partitioning is done and the installer runs mkfs.ext2
-F /dev/sda1 it hangs and the process goes Defunct. I’ve tried many
different layouts with/without LVM, with/without /home always the same
spot 33% ….


If it's the same issue as with my Ultra 10, you (1) either have to wait
longer or (2) have to remove your floppy disk drive from the controller
before doing an installation. #2 definitely saves some time.

Cheers,
Frank

mkfs.ext2 - state D partitioning stops at 33% /boot

[Mike Tremaine]

I spent a few hours trying different things on this but no luck.

Hardware: Sun Ultra 5 - 333mhz / 512MB  - Promise 100 PCI card as IDE 
interface..

Install Image:  2020-05-30/debian-10.0.0-sparc64-NETINST-1.iso

Boots CDROM and finds disks no problem.

Issue is after the partitioning is done and the installer runs mkfs.ext2 -F 
/dev/sda1  it hangs and the process goes Defunct. I’ve tried many different 
layouts with/without LVM, with/without /home always the same spot 33% ….

Details below but if anyone has any suggestions I’d love to hear them. I dd 
take the disk out and mount on another machine wiped, re-labeled it as sun type 
and all that. 

Details:

~ # lspci
00:01.0 PCI bridge: Oracle/SUN Simba Advanced PCI Bridge (rev 11)
00:01.1 PCI bridge: Oracle/SUN Simba Advanced PCI Bridge (rev 11)
01:01.0 Bridge: Oracle/SUN EBUS (rev 01)
01:01.1 Ethernet controller: Oracle/SUN Happy Meal 10/100 Ethernet [hme] (rev 
01)
02:01.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 11)
02:02.0 Mass storage controller: Promise Technology, Inc. PDC20267 
(FastTrak100/Ultra100) (rev 02)
02:03.0 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 
Controller (rev 61)
02:03.1 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 
Controller (rev 61)
02:03.2 USB controller: VIA Technologies, Inc. USB 2.0 (rev 63)
~ # 

~ # lsscsi 
[1:0:0:0]   (5) SONYCD-RW  CRX220E1 6YS1
[0:0:0:0]   diskATA OWC Mercury Elec2A0


~ # lsmod
Module  Size  Used by
nls_utf81581  1
isofs  40096  1
usb_storage59105  0
sd_mod 40655  0
t10_pi  4669  1 sd_mod
sr_mod 16402  1
crc_t10dif  2020  1 t10_pi
cdrom  49720  1 sr_mod
crct10dif_common1606  1 crc_t10dif
pata_pdc202xx_old   5223  1
ehci_pci4919  0
uhci_hcd   38066  0
ehci_hcd   69081  1 ehci_pci
libata213657  1 pata_pdc202xx_old
sunhme 29131  0
usbcore   225935  4 ehci_pci,usb_storage,ehci_hcd,uhci_hcd
scsi_mod  194244  4 sd_mod,usb_storage,libata,sr_mod
usb_common  7884  3 usbcore,ehci_hcd,uhci_hcd

~ # cat /proc/cpuinfo 
cpu : TI UltraSparc IIi (Sabre)
fpu : UltraSparc IIi integrated FPU
pmu : ultra12
prom: OBP 3.31.0 2001/07/25 20:36
type: sun4u
ncpus probed: 1
ncpus active: 1
D$ parity tl1   : 0
I$ parity tl1   : 0
Cpu0ClkTck  : 13d92d40
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis
MMU Type: Spitfire
MMU PGSZs   : 8K,64K,512K,4MB


DMESG partial...
[0.000125] PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36'
[0.000203] PROMLIB: Root node compatible: 
[0.000537] Linux version 5.6.0-2-sparc64 (debian-ker...@lists.debian.org) 
(gcc version 9.3.0 (Debian 9.3.0-12)) #1 Debian 5.6.14-1 (2020-05-23)
[0.000744] Unknown boot switch (--)
[0.000749] Unknown boot switch (--)
[0.001150] printk: bootconsole [earlyprom0] enabled
[0.001156] ARCH: SUN4U
.
.
.
[   14.365610] pata_pdc202xx_old :02:02.0: enabling device (0006 -> 0007)
[   14.365841] pata_pdc202xx_old :02:02.0: BMDMA: BAR4 is zero, falling 
back to PIO
[   14.393753] scsi host0: pata_pdc202xx_old
[   14.403284] scsi host1: pata_pdc202xx_old
[   14.403925] ata1: PATA max PIO4 cmd 0x1fe02000400 ctl 0x1fe02000408 irq 14
[   14.403940] ata2: PATA max PIO4 cmd 0x1fe02000410 ctl 0x1fe02000418 irq 14
[   14.567798] ata1.00: ATA-9: OWC Mercury Electra 3G SSD, R0522A0, max UDMA/133
[   14.567818] ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 0/32)
[   14.576646] scsi 0:0:0:0: Direct-Access ATA  OWC Mercury Elec 2A0  
PQ: 0 ANSI: 5
[   14.643016] hme :01:01.1 enp1s1f1: renamed from eth0
[   14.738048] ata2.00: ATAPI: SONYCD-RW  CRX220E1, 6YS1, max UDMA/33
[   14.744494] scsi 1:0:0:0: CD-ROMSONY CD-RW  CRX220E1  6YS1 
PQ: 0 ANSI: 5
[   14.899364] sr 1:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 
cdda tray
[   14.899382] cdrom: Uniform CD-ROM driver Revision: 3.20
[   14.911348] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   14.958572] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 
GiB)
[   14.958714] sd 0:0:0:0: [sda] Write Protect is off
[   14.958738] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   14.959684] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[   14.971598]  sda: sda1 sda2 sda3 sda4
[   14.988124] sd 0:0:0:0: [sda] Attached SCSI disk