Hello,
>
> As a matter of fact it just happened with our IDE drives after upgrading
>to 2.0.34, since we had read this, we downgraded to 2.0.33 and it works with
>no erros now. I
>don't intent to say that this is an important bug, but maybe it should be
>looked at.
I had this error messag
On Wed, 24 Jun 1998, Javier Fdz-Sanguino Pen~a wrote:
>
> As a matter of fact it just happened with our IDE drives after upgrading
> to 2.0.34, since we had read this, we downgraded to 2.0.33 and it works with
> no erros now. I
> don't intent to say that this is an important bug, but maybe
On Wed, 24 Jun 1998, Andreas Jellinghaus wrote:
> i have 40 identical computers here, and one of them has the same problems.
> i guess some trouble with the mainboard, but i'm not sure and could not
> investigate till today. all other machines work fine (with hard disk,
> 2 have network card probl
Well , its already off. Thanks for the tip. I downgraded to
2.0.33, and things are much more stable , so far, but I've seen a couple
of errors. I guess we'll have to wait a while longer and see if other
people report the same thing.
On 24 Jun 1998, Gregory S. Stark wrote:
> Are you run
>it as well.
> A typical error message is (this occurs on 2 of three drives):
>
>Jun 23 20:35:40 homey kernel: hdb: read_intr: status=0x59 { DriveReady
>SeekComplete DataRequest Error }
>Jun 23 20:35:40 homey kernel: hdb: read_intr: error=0x40 {
>UncorrectableError }, LBAsect=6766956, sec
> > > On Wed, Jun 24, 1998 at 12:24:52AM -0700, G John Lapeyre wrote:
> > > > A typical error message is (this occurs on 2 of three drives):
> > > >
> > > > Jun 23 20:35:40 homey kernel: hdb: read_intr: status=0x59 { DriveReady
> > > > SeekComplete DataRequest Error }
> > > > Jun 23 20:
As a matter of fact it just happened with our IDE drives after upgrading
to 2.0.34, since we had read this, we downgraded to 2.0.33 and it works with no
erros now. I
don't intent to say that this is an important bug, but maybe it should be
looked at.
Regards
Javi
On W
OK, I was wrong , its happening now with 2.0.33 too. However, its
happening to all three ide drives. I'd better figure it out fast
On Wed, 24 Jun 1998, Christian Meder wrote:
> On Wed, Jun 24, 1998 at 12:24:52AM -0700, G John Lapeyre wrote:
> > A typical error message is (thi
On Wed, Jun 24, 1998 at 12:24:52AM -0700, G John Lapeyre wrote:
> A typical error message is (this occurs on 2 of three drives):
>
> Jun 23 20:35:40 homey kernel: hdb: read_intr: status=0x59 { DriveReady
> SeekComplete DataRequest Error }
> Jun 23 20:35:40 homey kernel: hdb: read_intr: err
My file systems are getting trashed. I get errors and eventually
the system hung (couldn't shutdown). I switched back to 2.0.33 and
everything is fine. I'm not sure if overheating has something to do with
it as well.
A typical error message is (this occurs on 2 of three drive
Thanks to everyone that pointed out that the fat32 patches ARE in 2.0.34.
I assumed that fat32 remained a configure option, but it appears that it is
now a standard feature (of fat). At least that's why I could not find any
reference to fat32 in the configure scripts.
It must be a mess for the ke
I haven't tested it, but it really looks like Gordon Chaffee's
patches are included.
homey 4 > rgrep -i -r 'fat32' .
./fs/fat/cache.c: fat_bits == 16 ? EOF_FAT16 :
EOF_FAT3
2);
./fs/fat/inode.c: int fat32;
./fs/fat/in
"Bob" == Bob Nielsen <[EMAIL PROTECTED]> writes:
Bob> conclude that it probably is there (maybe in a different form
Bob> than the patches).
Bob> As usual, the documentation lags the code, of course.
The documentation is off on Alan Cox's site -- it seems you have to
activate NLS support and UTF8
On Tue, 9 Jun 1998 [EMAIL PROTECTED] wrote:
> I downloaded the sources for the 2.0.34 kernel and did a quick look through
> the files. The fat-32 patches do not seem to be in here. If 2.0.34 is to
> be released as a debian package, then I hope all of the patches that are in
> the 2.0.33 package
On Tue, Jun 09, 1998 at 07:42:27AM -0400, [EMAIL PROTECTED] wrote:
> I downloaded the sources for the 2.0.34 kernel and did a quick look through
> the files. The fat-32 patches do not seem to be in here. If 2.0.34 is to
> be released as a debian package, then I hope all of the patches that are in
I downloaded the sources for the 2.0.34 kernel and did a quick look through
the files. The fat-32 patches do not seem to be in here. If 2.0.34 is to
be released as a debian package, then I hope all of the patches that are in
the 2.0.33 package are added.
Also has anyone packaged the Real Time li
Luis Francisco Gonzalez <[EMAIL PROTECTED]> wrote:
> Precisely, in bo the boot-floppies had to disable pcmcia because it was
> broken. I guess you never had to install using a pcmcia network card.
> If we make changes to the kernels, let's make sure there is no broken
> dependent package.
I don't
Raul Miller wrote:
> Jim <[EMAIL PROTECTED]> wrote:
> > Speaking as a debian advocate, it would be highly embarrassing to try
> > to explain something like "Oh yeah, the new kernel is there, but you
> > can't use it yet since ..." where ... stems from the person's need for
> > some dependant packag
[EMAIL PROTECTED] said:
> How is this different from bo, where we also had three kernel versions
> available and only had pcmcia modules for the first two?
No difference. And no improvement. :)
-Jim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contac
Jim <[EMAIL PROTECTED]> wrote:
> Speaking as a debian advocate, it would be highly embarrassing to try
> to explain something like "Oh yeah, the new kernel is there, but you
> can't use it yet since ..." where ... stems from the person's need for
> some dependant package. Example: say he needs pcmc
[EMAIL PROTECTED] said:
> I don't agree that we have to delay the release of hamm to have 2.0.34
> as a hamm package.
I do :)
Speaking purely as a user, I think the job should be done right.
Speaking as a debian advocate, it would be highly embarrassing to try to
explain something like "Oh y
Ossama Othman <[EMAIL PROTECTED]> wrote:
> A month or two? Isn't the development kernel supposed to be released as
> "stable" by then?
Oh no, I don't think so. Kernel development seems to be caotic at this
time. Maintainers of different parts of the kernels are complaining
loudly because Linus h
Hi,
> There is apparently an updated driver on whatever the AIC7XXX driver's home
> site is. Maybe that should be included as a local patch for our source---at
> least up to this point, Alan Cox has been making it sound like 2.0.35 is a
> month or two away, at least.
A month or two? Isn't the
Wichert Akkerman wrote:
> Furthermore, 2.0.34 fixes a lot of security problems, not all of which
> are in the Debian 2.0.33 package IIRC
Yes, I saw a truely scarey post from Dave Miller listing security problems
in 2.0.x kernels that are fixed in 2.0.34. Many of them didn't have details,
becuase o
On Sat, Jun 06, 1998 at 06:18:19PM -0400, Ossama Othman wrote:
> > Yes, AIC7XXX is a problem with 2.0.34. This probably means that 2.0.35
> > will be
> > forthcoming.
> I've had no problems whatsoever with my AIC7880 onboard UW SCSI
> controller. It handles my SCSI-3 hard drive, SCSI-2 CD-ROM
Hi,
> Yes, AIC7XXX is a problem with 2.0.34. This probably means that 2.0.35 will
> be
> forthcoming.
I've had no problems whatsoever with my AIC7880 onboard UW SCSI
controller. It handles my SCSI-3 hard drive, SCSI-2 CD-ROM Drive and my
SCSI-1 DAT/DDS-2 tape drive just fine. Nevertheless,
On Sat, 6 Jun 1998, Jesse Goldman wrote:
> Hi,
>
> Looks to me like kernel 2.0.34 is more than just a bugfix release. The
> aic7xxx/pci driver changed *completely* with the result that my adaptec
> 2940AU no longer seems to work. I'd agree with the suggestion that 2.0.33
&g
How about ship Hamm with 2.0.33 as setup but include what's necessary for
2.0.34 the way Bo has 2.0.29 but includes the stuff for 2.0.30
--
http://benham.net/index.html
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++> E?
Hi,
Looks to me like kernel 2.0.34 is more than just a bugfix release. The
aic7xxx/pci driver changed *completely* with the result that my adaptec
2940AU no longer seems to work. I'd agree with the suggestion that 2.0.33
be kept around a bit longer.
J. Goldman
--
To UNSUBSCRIBE, ema
Luis Francisco Gonzalez <[EMAIL PROTECTED]> wrote:
> Let's be clear about what this means. We need to compile the kernel
> and all packages that depend on it, pcmcia-modules, boot-floppies,
> etc. (We could, I guess live with the boot-floppies being 2.0.33 but
> given that there is a mismatch betwe
Martin Mitchell wrote:
> I second this, 2.0.34 has undergone much testing in prereleases and is a
> further refinement of the stable branch of the kernel tree.
Let's be clear about what this means. We need to compile the kernel and all
packages that depend on it, pcmcia-modules, boot-floppies, etc.
Raul Miller <[EMAIL PROTECTED]> writes:
> I would like to recommend that linux 2.0.34 be made available as a
> part of hamm. This is because 2.0.34 is a bugfix-only upgrade to
> 2.0.33.
>
> However, I don't think we have enough experience with 2.0.34 to
> eliminate 2.0.33 from the distribution.
I would like to recommend that linux 2.0.34 be made available as a
part of hamm. This is because 2.0.34 is a bugfix-only upgrade to
2.0.33.
However, I don't think we have enough experience with 2.0.34 to
eliminate 2.0.33 from the distribution. So both should be available.
--
Raul
--
To UNSU
Miquel van Smoorenburg wrote:
> According to Dale Scheetz:
> > So, where do I find the source? Helsinki only has 2.0.33?
>
> I downloaded 2.0.34 from ftp.funet.fi yesterday morning (the patch that is,
> I did not check to see if a complete kernel was there).
It was, I did.
Luis.
--
Luis Francis
According to Dale Scheetz:
> So, where do I find the source? Helsinki only has 2.0.33?
I downloaded 2.0.34 from ftp.funet.fi yesterday morning (the patch that is,
I did not check to see if a complete kernel was there).
You can also find a copy of the 2.0.34 patch on
ftp://ftp.linux.org.uk/pub/li
So, where do I find the source? Helsinki only has 2.0.33?
On Fri, 5 Jun 1998, Wichert Akkerman wrote:
> Previously Miquel van Smoorenburg wrote:
> > Well, our news server (Diablo, #threehundredsomething in the top1000)
> > crashed regulary with all the 2.0.x kernels but with the later 2.0.34pre
>
Previously Miquel van Smoorenburg wrote:
> Well, our news server (Diablo, #threehundredsomething in the top1000)
> crashed regulary with all the 2.0.x kernels but with the later 2.0.34pre
> kernels it has been rock-stable.
2.0.33 regulary hangs on newer Intel chipsets. I installed Debian on a
frie
In article <[EMAIL PROTECTED]>,
Luis Francisco Gonzalez <[EMAIL PROTECTED]> wrote:
>I guess the kernel-maintainer is the only one that can evaluate if
>there are any security improvements that should make it into hamm. Otherwise,
>let's not put new code into the freeze. Debian 2.1 should not take l
G John Lapeyre wrote:
> They have included the FAT32 support. Many users need to mount
> their win95 partition. Many can't even install without support, as they
> need to install from a FAT32 partition. I had this problem installing on a
> machine a few months ago. You had to patch 2.0.33 t
They have included the FAT32 support. Many users need to mount
their win95 partition. Many can't even install without support, as they
need to install from a FAT32 partition. I had this problem installing on a
machine a few months ago. You had to patch 2.0.33 to get it.
John
J
40 matches
Mail list logo
