Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #207955 > unrolled thread

Re: Is Debian 9 supposed to work on a Geode?

Back to article view | Back to linux.debian.user

Contents

  Re: Is Debian 9 supposed to work on a Geode? bw <bwtnguy@yahoo.com> - 2019-04-29 01:10 +0200
    Re: Is Debian 9 supposed to work on a Geode? Tixy <tixy@yxit.co.uk> - 2019-04-29 07:50 +0200
      Re: Is Debian 9 supposed to work on a Geode? Curt <curty@free.fr> - 2019-04-29 10:00 +0200
        Re: Is Debian 9 supposed to work on a Geode? Thomas Pircher <thp+debian@p5r.uk> - 2019-04-29 10:10 +0200
          Re: Is Debian 9 supposed to work on a Geode? Tixy <tixy@yxit.co.uk> - 2019-04-29 10:40 +0200
            Re: Is Debian 9 supposed to work on a Geode? Thomas Pircher <thp+debian@p5r.uk> - 2019-04-29 13:20 +0200
          Re: Is Debian 9 supposed to work on a Geode? Curt <curty@free.fr> - 2019-04-29 14:40 +0200
    Re: Is Debian 9 supposed to work on a Geode? Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2019-05-02 15:10 +0200
      Re: Is Debian 9 supposed to work on a Geode? Jonas Smedegaard <jonas@jones.dk> - 2019-05-02 15:30 +0200
        Re: Is Debian 9 supposed to work on a Geode? Brian <ad44@cityscape.co.uk> - 2019-05-02 21:50 +0200
          Re: Is Debian 9 supposed to work on a Geode? Francesco Poli <invernomuto@paranoici.org> - 2019-05-02 23:40 +0200
            Re: Is Debian 9 supposed to work on a Geode? Brian Potkin <brian@copernicus.org.uk> - 2019-05-03 21:50 +0200
      Re: Is Debian 9 supposed to work on a Geode? deloptes <deloptes@gmail.com> - 2019-05-02 23:30 +0200
        Re: Is Debian 9 supposed to work on a Geode? Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2019-05-05 18:00 +0200
          Re: Is Debian 9 supposed to work on a Geode? deloptes <deloptes@gmail.com> - 2019-05-05 19:40 +0200

#207955 — Re: Is Debian 9 supposed to work on a Geode?

In-Reply-To: <20190428235815.09cfe597@tag.xn--rombobjrn-67a.se>

><Bjorn@xn--rombobjrn-67a.se>
>So if this processor is actually not supported anymore (contrary to the
>information that Jonas Smedegaard linked to), then it looks like I
>should get started on replacing the hardware, rather than putting a lot
>of work into temporary solutions. It's sad to have to throw away
>working hardware, but that's the way it is in the whole industry.
>Debian is at least better than many others in that regard.

Before you dump it, I'd sure confirm the situation, document the flags and 
file a bug against the release notes, so maybe that can get fixed in 
buster release notes?  You never know, you might have some botched 
upgrade issue. I always try 'acpi=off single' kernel params first, then 
start disabling everything I can in BIOS or physically removing hardware 
if single user mode won't boot.  The param 'systemd.restore_state=0' got 
me into otherwise unbootable machines more than once.

I know how it is, I have a nice old K6-3 amd @450mHz system, around 1996 I 
think?  I can't run stretch on it, but I still use it. Just can't bring 
myself to trash it.

Peace out,
bw

[toc] | [next] | [standalone]

#207962

Hi bw

On Sun, 2019-04-28 at 18:52 -0400, bw wrote:
> In-Reply-To: <20190428235815.09cfe597@tag.xn--rombobjrn-67a.se>

All your mails to the list seem to be a little broken. The first line
of each email starts with a line like the above and your replies aren't
appearing threaded correctly, presumably because that line should be in
the email headers not the body. Guess this is a bug with your mail user
agent (Alpine) and not something specific you are doing?

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#207967

On 2019-04-29, Tixy <tixy@yxit.co.uk> wrote:
> Hi bw
>
> On Sun, 2019-04-28 at 18:52 -0400, bw wrote:
>> In-Reply-To: <20190428235815.09cfe597@tag.xn--rombobjrn-67a.se>
>
> All your mails to the list seem to be a little broken. The first line
> of each email starts with a line like the above and your replies aren't
> appearing threaded correctly, presumably because that line should be in
> the email headers not the body. Guess this is a bug with your mail user
> agent (Alpine) and not something specific you are doing?
>

It is not a bug in Alpine. It is not a bug at all. It is an intentional
user configuration ('Reply Leadin' parameter). It is also not a
'Reply-To' header that somehow got lowered or dropped into the email
body by inadvertence or wrong-headed design.

Apparently, the 'In-Reply-To' string must educe some deficiency (or
confusion) in the Evolution software you use, however.

Maybe that lead-in violates some RFC, although you'd think what's in the
header's in the header and what ain't ain't and ne'er the twain shall
meet.

At any rate, bw threads fine here, so it must be you (or me).

-- 
The major, who had been a great fencer, did not believe in bravery, and spent
much time while we sat in the machines correcting my grammar. He had
complimented me on how I spoke Italian, and we talked together very easily. One
day I had said that Italian seemed such an easy language to me that I could not
take a great interest in it; everything was so easy to say. "Ah, yes," the
major said. "Why, then, do you not take up the use of grammar?" - "Another Country"

[toc] | [prev] | [next] | [standalone]

#207968

Curt wrote:
> Maybe that lead-in violates some RFC, although you'd think what's in the
> header's in the header and what ain't ain't and ne'er the twain shall
> meet.
> 
> At any rate, bw threads fine here, so it must be you (or me).

It's you -- or rather bw's MUA, I'm afraid. :-)
His mails don't thread in neomutt neither, specifically because the
headers sent by his MUA don't include neither the Reference nor the
In-Reply-To fields.

Thomas

[toc] | [prev] | [next] | [standalone]

#207970

On Mon, 2019-04-29 at 09:08 +0100, Thomas Pircher wrote:
> Curt wrote:
> > Maybe that lead-in violates some RFC, although you'd think what's
> > in the
> > header's in the header and what ain't ain't and ne'er the twain
> > shall
> > meet.
> > 
> > At any rate, bw threads fine here, so it must be you (or me).
> 
> It's you -- or rather bw's MUA, I'm afraid. :-)
> His mails don't thread in neomutt neither, specifically because the
> headers sent by his MUA don't include neither the Reference nor the
> In-Reply-To fields.

Yes, I checked that before posting. I also checked the web archives [1]
where all of bw's messages appear under a "<Possible follow-ups>"
heading. I'm guessing the archive is falling back to threading by
matching the subject line, as with Curt's MUA?

[1] https://lists.debian.org/debian-user/2019/04/thrd3.html

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#207973

Tixy wrote:
> I'm guessing the archive is falling back to threading by
> matching the subject line, as with Curt's MUA?

The Debian list admins will have a more authoritative answer then mine,
but I searched a bit about "possible follow-ups" in and this [1] old
posting by the author of MHonArc confirms your guess.

Thomas

[1] https://www.mhonarc.org/archive/html/mhonarc-users/1999-02/msg00029.html

[toc] | [prev] | [next] | [standalone]

#207974

On 2019-04-29, Thomas Pircher <thp+debian@p5r.uk> wrote:
> Curt wrote:
>> Maybe that lead-in violates some RFC, although you'd think what's in the
>> header's in the header and what ain't ain't and ne'er the twain shall
>> meet.
>> 
>> At any rate, bw threads fine here, so it must be you (or me).
>
> It's you -- or rather bw's MUA, I'm afraid. :-)
> His mails don't thread in neomutt neither, specifically because the
> headers sent by his MUA don't include neither the Reference nor the
> In-Reply-To fields.

I now understand that bw's mails do not comprise those thread-critical
fields. As an Alpine user myself, I can only wonder how he manages it,
and, more particularly, why he manages it. I guess my slrn news client
(I read the list through an NTTP host) must work it out via the
'Subject:' line (as suggested by Tixy elsewhere), threading acceptably
even in the absence of the missing fields.

Whether this whole business has any relation to the custom lead-in
string in his email bodies is a matter for conjecture.

A bientôt.

> Thomas
>
>


-- 
The major, who had been a great fencer, did not believe in bravery, and spent
much time while we sat in the machines correcting my grammar. He had
complimented me on how I spoke Italian, and we talked together very easily. One
day I had said that Italian seemed such an easy language to me that I could not
take a great interest in it; everything was so easy to say. "Ah, yes," the
major said. "Why, then, do you not take up the use of grammar?" - "Another Country"

[toc] | [prev] | [next] | [standalone]

#208036

[Multipart message — attachments visible in raw view] — view raw

bw wrote:
> Before you dump it, I'd sure confirm the situation, document the flags and 
> file a bug against the release notes, so maybe that can get fixed in 
> buster release notes?

I filed this bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928340

Björn Persson

[toc] | [prev] | [next] | [standalone]

#208039

[Multipart message — attachments visible in raw view] — view raw

Quoting Björn Persson (2019-05-02 15:04:53)
> bw wrote:
> > Before you dump it, I'd sure confirm the situation, document the 
> > flags and file a bug against the release notes, so maybe that can 
> > get fixed in buster release notes?
> 
> I filed this bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928340

Great, detailed yet precise bugreport!

I sincerely hope the response won't the equivalent of "whoops too bad, 
train left the station a bit too early but is now gone...!"


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#208053

On Thu 02 May 2019 at 15:27:30 +0200, Jonas Smedegaard wrote:

> Quoting Björn Persson (2019-05-02 15:04:53)
> > bw wrote:
> > > Before you dump it, I'd sure confirm the situation, document the 
> > > flags and file a bug against the release notes, so maybe that can 
> > > get fixed in buster release notes?
> > 
> > I filed this bug report:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928340
> 
> Great, detailed yet precise bugreport!
> 
> I sincerely hope the response won't the equivalent of "whoops too bad, 
> train left the station a bit too early but is now gone...!"

Ben Hutchings replies:

  > The Geode LX's CPUID has family=5 (586), but I agree with your
  > understanding that it has all the important features of a 686 and
  > should still be supported.  In fact, I've specifically enabled
  > continued support for it in the current (buster/sid) 686 kernel
  > configuration.
  >
  > I'm afraid I don't have any immediate ideas for how to fix or debug
  > this.

>From my point of view (as I have said before) debugging would involve
installing to a USB stick. There is nothing to lose by trying this.

In #917569

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917569

Francesco Poli treats upgrading one buster Soekris net5501 installation
to another one. This implies he might very well have been running that
device on stretch. Or, for that matter, running on a previous buster.

I have previously found Francesco to be very co-operative, so I have put
him in a Cc:.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#208058

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2 May 2019 20:49:28 +0100 Brian wrote:

[...]
> In #917569
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917569
> 
> Francesco Poli treats upgrading one buster Soekris net5501 installation
> to another one. This implies he might very well have been running that
> device on stretch. Or, for that matter, running on a previous buster.
> 
> I have previously found Francesco to be very co-operative, so I have put
> him in a Cc:.

Hello!  :-)
I am afraid I will disappoint you a bit this time...   :-p

The only thing I can say is that I run Debian testing on my Soekris
net5501. The box has always tracked Debian testing, hence it only used
to run stretch when stretch was testing (that is to say, *before*
stretch was released as stable). It currently runs an updated buster
(== current Debian testing) and the Linux kernel is able to boot.

I don't know whether the bug I reported (#917569) against
linux/4.19.12-1 corresponds to the same issue that Björn is
experiencing with linux/4.9.168-1 (#928340)...

I am sorry I cannot be of more help.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#208089

On Thu 02 May 2019 at 23:33:06 +0200, Francesco Poli wrote:

> On Thu, 2 May 2019 20:49:28 +0100 Brian wrote:
> 
> [...]
> > In #917569
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917569
> > 
> > Francesco Poli treats upgrading one buster Soekris net5501 installation
> > to another one. This implies he might very well have been running that
> > device on stretch. Or, for that matter, running on a previous buster.
> > 
> > I have previously found Francesco to be very co-operative, so I have put
> > him in a Cc:.
> 
> Hello!  :-)
> I am afraid I will disappoint you a bit this time...   :-p

Not at all. You have provided exactly the quality of information
needed.

> The only thing I can say is that I run Debian testing on my Soekris
> net5501. The box has always tracked Debian testing, hence it only used
> to run stretch when stretch was testing (that is to say, *before*
> stretch was released as stable). It currently runs an updated buster
> (== current Debian testing) and the Linux kernel is able to boot.

Björn has exactly the same machine as you. You use yours on buster;
he cannot even use it on stretch. Aren't computers wonderful? :)

> I don't know whether the bug I reported (#917569) against
> linux/4.19.12-1 corresponds to the same issue that Björn is
> experiencing with linux/4.9.168-1 (#928340)...
> 
> I am sorry I cannot be of more help.

My machine doesn't differ in any significant way from Björn's. You
motivated me to to upgrade from stretch, where it worked, to buster.
No problem booting, so my answer to the subject header (Is Debian 9
supposed to work on a Geode?) is a resounding "yes".

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#208057

Björn Persson wrote:

> bw wrote:
>> Before you dump it, I'd sure confirm the situation, document the flags
>> and file a bug against the release notes, so maybe that can get fixed in
>> buster release notes?
> 
> I filed this bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928340
> 
> Björn Persson

Have you tried command line init=/lib/sysvinit/init? This is to rule out
systemd

Next thing I would do is try boot from usb - I do not see in the log
assignment to the disk, so I suspect the hard drive is not assigned
properly and can not be accessed - are you booting from a card, or disk or
usb? What if you try to disable pata_amd?

[    6.114215] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xe000 irq
14
[    6.156075] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xe008 irq
15
...
...
[    6.407833] ata1.00: supports DRM functions and may not be fully
accessible
[    6.449569] ata1.00: ATA-9: Samsung SSD 850 PRO 1TB, EXM02B6Q, max
UDMA/133
[    6.491306] ata1.00: 2000409264 sectors, multi 1: LBA48 NCQ (depth 0/32)

and nothing like sda or hda.

In my case exactly this was the problem, so I had to enable old drivers for
hdd in combination with libata so that it might work - took me ages to find
out, but you have a newer generation, could be different, although 
Processor family (Geode GX/LX)  is the same - it says "Select this for AMD
Geode GX and LX processors.".

<*> ATA/ATAPI/MFM/RLL support (DEPRECATED)  --->
        <*>   generic ATA/ATAPI disk support
        [*]     ATA disk support

        [*]   legacy /proc/ide/ support 
        
        <M>   Cyrix/National Semiconductor CS5530 MediaGX chipset support
        
I could give you the kernel packages if you wish, but can not guarantee, it
would work.
If you can tell what is your chipset - I could let it configure and compile,
if you wish.

Another option is that you miss something in the initrd - if you can enter
initrd (init=/bin/sh) and debug would be a +. 

regards

[toc] | [prev] | [next] | [standalone]

#208215

[Multipart message — attachments visible in raw view] — view raw

deloptes wrote:
> I do not see in the log
> assignment to the disk, so I suspect the hard drive is not assigned
> properly and can not be accessed - are you booting from a card, or disk or
> usb? What if you try to disable pata_amd?
> 
> [    6.114215] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xe000 irq
> 14
> [    6.156075] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xe008 irq
> 15
> ...
> ...
> [    6.407833] ata1.00: supports DRM functions and may not be fully
> accessible
> [    6.449569] ata1.00: ATA-9: Samsung SSD 850 PRO 1TB, EXM02B6Q, max
> UDMA/133
> [    6.491306] ata1.00: 2000409264 sectors, multi 1: LBA48 NCQ (depth 0/32)
> 
> and nothing like sda or hda.

Yes, some kind of disk access problem seems likely, seeing that the
disk activity light gets stuck on. This SATA SSD is the one and only
storage device in the box, and the bios and Grub read it just fine, but
maybe Linux somehow can't.

Björn Persson

[toc] | [prev] | [next] | [standalone]

#208225

Björn Persson wrote:

> Yes, some kind of disk access problem seems likely, seeing that the
> disk activity light gets stuck on. This SATA SSD is the one and only
> storage device in the box, and the bios and Grub read it just fine, but
> maybe Linux somehow can't.

I suggested to try booting without systemd and if it does not work with
init=/bin/sh - then try find out what is missing. I recall problem with
udev not createing devices, but could be anything - the only way to find
out is to get into the boot/initrd shell.

It could be also you are missing drivers in the initrd - but therea re so
many possible reasons for failure, I would not speculate on them - just go
into the shell and try find out what is the issue. 

regards

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web