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 messages
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
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:
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 (this
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
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:
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,
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
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
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 it
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
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 are
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
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;
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
[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? Contact
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 package. Example:
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 see
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
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
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 has a
[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
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 pcmcia.
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
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. So
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 between
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, email
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?
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
be kept around a bit longer
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, if
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 Drive
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
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
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
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
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 long
36 matches
Mail list logo
