Re: 2.2r3 test images
Bernd Hentig <bernd@ixsoft.de> writes:
> Hello
>
> > Hi,
> >
> > You'll be pleased to hear that I gave open.hands.com (a.k.a
> > cdimage.debian.org) a brain transplant today, so instead of being an
> > Athlon on a VIA chipset motherboard, it's now a PIII 750, on an Intel
> > chipset, with 512MB of new RAM
>
> That means you have *downgraded* the system ?
Nah -- it was an Athlon 650 which I'd guess is supposed to be slower,
unless you're saying any migration to Intel is a downgrade by
definition?
Regardless of theoretical comparisons, the PIII seems to be driving
the disks something like 3 times faster during the mkisofs, for
example (this is purely a subjective measure, by watching it, so is
probably wildly inaccurate)
> What was the reason for this decision ?
The old Athlon/VIA combo was flakier than a snowstorm when moving a
lot of data from/to the disks. To the extent that I don't think it
managed to create more than 3 CD images in a row without crashing, but
worse than that, it was flipping bits coming of off the disks about
once every 200MB (i.e. 3 or 4 bad bits per CD) which also makes one
wonder what people were downloading from the archive.
This was with every combination of 2.2.17/2.2.19/2.4.3/2.4.3-ac11, DMA
on/off, IDE1 in use or not, etc. that i could think of in about 7
hours of sodding about trying to get it stable.
So that's why I made that decision.
> I know that there have been problems with VIA chipsets on Athlon
> mainboards, but these should have gone with kernel 2.4.3 ?
Bzzt. wrong --- unless of course all this was caused by an unrelated
hardware fault, but the reported symptoms seem to match what's been
reported, and I tried it with the latest -ac11 patch, so I think it's
not been fixed.
> > What do people think about this? This matches the (slightly broken)
> > state of the main archive at present, so either I kludge debian-cd to
> > exclude bulkmail, or we wait (and wait?) for the archive to be fixed.
>
> What is the difference between bulkmail and bulk_mailer from majordomo ?
No idea --- don't really care to be honest.
> > Please report how you get on with these images, because the sooner I
> > get positive feadback, the sooner i can declare them official.
> >
> > Cheers, Phil.
> >
> > P.S. I just noticed that the alpha CDs came out with a 698865664 byte
> > CD 1_NONUS, which is too big, so I'll have to re-do them.
>
> Well, nowadays 700 MB CD-R are even cheaper than 650 MB, so I really
> don't mind. Is there any *real* reason why the 650 MB limit is still kept ?
> I mean, 700 MB CD-R can be read by all modern CDROM drives except 1x/2x
> proprietary drives from about 10 years ago. Ok, I understand Pentium
> processors also have to be compatible with 8088 since there is so many
> software written for 8088, but does it really affect more than 0.001 %
> of all users ?
I've no idea, but I'd guess that there might be a problem pressing
larger CDs in bulk --- would someone that actually presses CDs in bulk
care to enlighten us?
As it happens, we can fit the CDs onto 3x650 per architecture at
present, so we might as well, because otherwise we just have a
slightly emptier CD#3, but the extra space could be handy in future,
so could anyone that knows a good reason not to go to 700MB / image in
the future, please tell us what it is.
> I'm only aware that the new CD-R 90/99 may pose some problems on
> modern drives and that the CD-R 144/200 need a BIOS or even laser
> upgrade to be read successfully. Maybe it's time for a Debian DVD
> ;-) (yes, I will test this with debian-cd once I can get hold of a
> DVD-R burner or compatible DVD-RW)
Apparently making DVDs poses interesting problems because of the 2GB
file size limit. I hear there is a solution, but didn't find out what
it was.
Cheers, Phil.
--
Say no to software patents! http://petition.eurolinux.org/
Philip Hands. +44 (0)20 7744 6244 philip.hands@uk.alcove.com
Alcove -- Liberating Software http://www.alcove.com/
http://www.hands.com/ phil@hands.com http://www.uk.debian.org/
Reply to: