[EMAIL PROTECTED] wrote:
> On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote:
>> I've asked James Cameron, pptp project lead, to try a test to force
>> the server side to issue a CCP DOWN, to make sure the client-side
>> kernel ppp_generic module does the right thing and drops packets.
>
[EMAIL PROTECTED] wrote:
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote:
I've asked James Cameron, pptp project lead, to try a test to force
the server side to issue a CCP DOWN, to make sure the client-side
kernel ppp_generic module does the right thing and drops packets.
I've
> grub stable <= 0.90.0 does not work on Dell 8450s.
>
> I really like the feature set of grub, but I guess the simplicity of
> lilo should not be undervalued.
grub-0.5.97-3.20010625.src.rpm from Red Hat rawhide works fine on Dell
PowerEdge 8450s.
Thanks,
Matt
--
Matt Domsch
Sr. Software
grub stable = 0.90.0 does not work on Dell 8450s.
I really like the feature set of grub, but I guess the simplicity of
lilo should not be undervalued.
grub-0.5.97-3.20010625.src.rpm from Red Hat rawhide works fine on Dell
PowerEdge 8450s.
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer
> > can someone please recommend a motherboard that can carry four CPUs,
> > either AMD or Intel (but other than Pentium III Xeon 700
> > Mhz) capable of> > running Linux?
>
> If you're going to go quad then you're usually better off
> dealing with a big
> company like Dell or IBM than going
can someone please recommend a motherboard that can carry four CPUs,
either AMD or Intel (but other than Pentium III Xeon 700
Mhz) capable of running Linux?
If you're going to go quad then you're usually better off
dealing with a big
company like Dell or IBM than going homebrew.
> my config settings .. The settings, and kernels I'm trying (at least
> 2.4.3-ac9) work on other Dell boxes here, such as the 2450, and 6350
> (with same internals, ie the raid (dual channel) + nic)...
>
> Quick spec of the box is:
> Dell PowerEdge 8450
> 4x550 Xeon / 2gig
>
my config settings .. The settings, and kernels I'm trying (at least
2.4.3-ac9) work on other Dell boxes here, such as the 2450, and 6350
(with same internals, ie the raid (dual channel) + nic)...
Quick spec of the box is:
Dell PowerEdge 8450
4x550 Xeon / 2gig
Onboard
> That one's mine. It should be:
>scsi_set_pci_device(shpnt, pdev);
Can you please try this patch and see if it works for you?
diff -burN linux-2.4.4/drivers/scsi/fdomain.c linux/drivers/scsi/fdomain.c
--- linux-2.4.4/drivers/scsi/fdomain.c Fri Apr 27 15:59:18 2001
+++
> > +if(pdev!=NULL)
> > scsi_set_pci_device(shpnt->pci_dev, pdev);
>
> I suspect it should be
>
> if(shpnt->pci_dev)
>
> but the effect is identical
That one's mine. It should be:
scsi_set_pci_device(shpnt, pdev);
There's no reason to check if pdev != NULL first, as it's
+if(pdev!=NULL)
scsi_set_pci_device(shpnt-pci_dev, pdev);
I suspect it should be
if(shpnt-pci_dev)
but the effect is identical
That one's mine. It should be:
scsi_set_pci_device(shpnt, pdev);
There's no reason to check if pdev != NULL first, as it's NULL in the
That one's mine. It should be:
scsi_set_pci_device(shpnt, pdev);
Can you please try this patch and see if it works for you?
diff -burN linux-2.4.4/drivers/scsi/fdomain.c linux/drivers/scsi/fdomain.c
--- linux-2.4.4/drivers/scsi/fdomain.c Fri Apr 27 15:59:18 2001
+++
Thanks everyone for your input again. I've made the changes suggested, and
would appreciate this being applied to Linus' and Alan's trees. This is
necessary for solving the "what disk does BIOS think is my boot disk"
problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit.
Jeff
Thanks everyone for your input again. I've made the changes suggested, and
would appreciate this being applied to Linus' and Alan's trees. This is
necessary for solving the what disk does BIOS think is my boot disk
problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit.
Jeff
> PCI ids can be derived from bus/slot/function.
Even better. I'll remove the extraneous fields then, and only return those.
typedef struct scsi_pci {
unsigned char bus_number;
unsigned intdevfn; /* encoded device & function index
*/
} Scsi_Pci;
Thanks,
Matt
--
Thanks everyone for your input.
Doug Gilbert said:
> SANE (and probably some other applications) parses the
> output of 'cat /proc/scsi/scsi' so any change to its
> format may trip SANE up. How about another entry in
> the /proc/scsi directory that has a more parsable format
> (e.g. xml :-) ).
Thanks everyone for your input.
Doug Gilbert said:
SANE (and probably some other applications) parses the
output of 'cat /proc/scsi/scsi' so any change to its
format may trip SANE up. How about another entry in
the /proc/scsi directory that has a more parsable format
(e.g. xml :-) ).
This
PCI ids can be derived from bus/slot/function.
Even better. I'll remove the extraneous fields then, and only return those.
typedef struct scsi_pci {
unsigned char bus_number;
unsigned intdevfn; /* encoded device function index
*/
} Scsi_Pci;
Thanks,
Matt
--
> An ioctl might be better. We already have an ioctl for
> querying the lun
> information for a disk. We could also return the bus
> information for its
> controller(s) [remember multipathing]
I provide such, and a test program at http://domsch.com/linux/scsi for
trying it out.
Thanks,
Matt
An ioctl might be better. We already have an ioctl for
querying the lun
information for a disk. We could also return the bus
information for its
controller(s) [remember multipathing]
I provide such, and a test program at http://domsch.com/linux/scsi for
trying it out.
Thanks,
Matt
--
> > > Linus has spoken, and 2.4.x now requires swap = 2x RAM.
> >
> > I think I missed this. What possible value does this have?
A good write-up of the discussion can be found at:
http://kt.zork.net/kernel-traffic/kt20010126_104.html#2
My concern is that if there continues to be a 2GB swap
Linus has spoken, and 2.4.x now requires swap = 2x RAM.
I think I missed this. What possible value does this have?
A good write-up of the discussion can be found at:
http://kt.zork.net/kernel-traffic/kt20010126_104.html#2
My concern is that if there continues to be a 2GB swap
Linus has spoken, and 2.4.x now requires swap = 2x RAM.
But, the 2GB per swap partition limit still exists, best as we can tell.
So, we sell machines with say 8GB RAM. We need 16GB swap, but really we
need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a
2GB swap partition
The final aacraid driver for Linux kernels 2.2.x and 2.4.x are now posted at
http://domsch.com/linux.
Changes from aacraid v1.0.7 for 2.2.x are in PERCID_add.patch:
- MAINTAINERS file update
- PCI ID update
Changes from aacraid beta for 2.4.x include:
- MAINTAINERS file update
- PCI ID update
-
The final aacraid driver for Linux kernels 2.2.x and 2.4.x are now posted at
http://domsch.com/linux.
Changes from aacraid v1.0.7 for 2.2.x are in PERCID_add.patch:
- MAINTAINERS file update
- PCI ID update
Changes from aacraid beta for 2.4.x include:
- MAINTAINERS file update
- PCI ID update
-
Linus has spoken, and 2.4.x now requires swap = 2x RAM.
But, the 2GB per swap partition limit still exists, best as we can tell.
So, we sell machines with say 8GB RAM. We need 16GB swap, but really we
need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a
2GB swap partition
> I have one additional user space only idea:
> have you tried raw-io? bind a raw device to the partition, IIRC raw-io
> is always in 512 byte units.
Steven Tweedie responded to my question about that:
> Raw IO is subject to the same limits as other IO, because
> ultimately it uses the same
I have one additional user space only idea:
have you tried raw-io? bind a raw device to the partition, IIRC raw-io
is always in 512 byte units.
Steven Tweedie responded to my question about that:
Raw IO is subject to the same limits as other IO, because
ultimately it uses the same route
> > While we can read and write to this sector in the kernel
> > partition code, we have
> > no way for userspace to update this partition block.
>
> Are you sure?
I'm not sure, but when I asked about this in January, I suggested having an
IOCTL that get/set
While we can read and write to this sector in the kernel
partition code, we have
no way for userspace to update this partition block.
Are you sure?
I'm not sure, but when I asked about this in January, I suggested having an
IOCTL that get/set blksize_size[MAJOR(dev)][MINOR(dev)], which
> I haven't seen this driver, but if it uses the SCSI layer instead
> of being a "pure" block driver then I can see a slight problem
> in that currently only understand max sg entry limits and not
> total request sizes. I would rather fix this limitation then, and
> would also be interested to
> I see in the archives of this mailing list that someone was
> working on the
> aacraid driver for the 2.4 kernel however that post was
> almost 2 months old.
Adaptec is still working on it. Basically (and as Jason discovered), the
driver and firmware can't handle single I/O requests larger
I see in the archives of this mailing list that someone was
working on the
aacraid driver for the 2.4 kernel however that post was
almost 2 months old.
Adaptec is still working on it. Basically (and as Jason discovered), the
driver and firmware can't handle single I/O requests larger than
I haven't seen this driver, but if it uses the SCSI layer instead
of being a "pure" block driver then I can see a slight problem
in that currently only understand max sg entry limits and not
total request sizes. I would rather fix this limitation then, and
would also be interested to know if
> I'm in need for aacraid support for the 2.4 kernel. Does anyone know
> when this is supposed to arrive? Are there any patches I can
> use? etc..
The aacraid driver is still being modified to work with the 2.4 kernel,
nothing has been released yet. Releasing this driver soon is a very high
I'm in need for aacraid support for the 2.4 kernel. Does anyone know
when this is supposed to arrive? Are there any patches I can
use? etc..
The aacraid driver is still being modified to work with the 2.4 kernel,
nothing has been released yet. Releasing this driver soon is a very high
Hi Tom. Thanks for writing.
> Since this machine has Quantum drives I guess this is my
> problem. Does anyone
> know if this code is still actually necessary? It seems
> it's been there a
> while. It's disappointing to not get full performance out of
> the hardware you
> have.
Yes,
Hi Tom. Thanks for writing.
Since this machine has Quantum drives I guess this is my
problem. Does anyone
know if this code is still actually necessary? It seems
it's been there a
while. It's disappointing to not get full performance out of
the hardware you
have.
Yes, that code
> From: Stephen Clouse [mailto:[EMAIL PROTECTED]]
> We have a development SMP machine which runs a myriad of
> server applications for
> our development purposes -- Apache, Oracle, several others.
> Under 2.4.0 the
> machine locks up, seemingly at random. Usually it simply
> stops responding
From: Stephen Clouse [mailto:[EMAIL PROTECTED]]
We have a development SMP machine which runs a myriad of
server applications for
our development purposes -- Apache, Oracle, several others.
Under 2.4.0 the
machine locks up, seemingly at random. Usually it simply
stops responding
> I want to run kernel 2.2.18 with aacraid support. Does anyone
> know where I can get the aacraid patches?
Hi David. Thanks for writing. This question has come up a number of times
lately, so I'll respond to the LK list too.
The open-source aacraid driver (formerly named percraid) is
I want to run kernel 2.2.18 with aacraid support. Does anyone
know where I can get the aacraid patches?
Hi David. Thanks for writing. This question has come up a number of times
lately, so I'll respond to the LK list too.
The open-source aacraid driver (formerly named percraid) is included
Linus, below is a trivial patch to pci.c, and applies against test12-pre5.
In -test11, tmp was declared. Somehow by 12-pre4, it got lost. This puts
it back. It's needed in the BITS_PER_LONG == 64 case.
Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team
diff -burN
Linus, below is a trivial patch to pci.c, and applies against test12-pre5.
In -test11, tmp was declared. Somehow by 12-pre4, it got lost. This puts
it back. It's needed in the BITS_PER_LONG == 64 case.
Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team
diff -burN
I don't believe that v1.09 (as in Red Hat Linux 7) has this problem, but
does have fixes over-and-above 1.07 (particularly, 1.07 and v1.08 touch
user-space inappropriately, 1.09 fixes). If PeterJ can't get to it before
2.2.18final, Alan, would you consider putting in the v1.09 driver?
Thanks,
I don't believe that v1.09 (as in Red Hat Linux 7) has this problem, but
does have fixes over-and-above 1.07 (particularly, 1.07 and v1.08 touch
user-space inappropriately, 1.09 fixes). If PeterJ can't get to it before
2.2.18final, Alan, would you consider putting in the v1.09 driver?
Thanks,
You can use an initial ramdisk (initrd), and specify the load order of your
drivers (driver for internal disk first, qlogic driver second). That
removes the dependency on the static link order in hosts.c.
Thanks,
Matt
-Original Message-
From: Klaus Naumann [mailto:[EMAIL PROTECTED]]
Attached is my patch (against 2.4.0-test9) to add EFI GUID Partition Table
support to the Linux kernel, specifically for IA-64. This code is licensed
under the GPL.
To enable support, add CONFIG_EFI_PARTITION=y to your config files.
Special thanks to Andries Brouwer for his assistance in
It's likely the megaraid driver. Try the megaraid driver that's in the
latest 2.2.18pre.
Thanks,
Matt
-Original Message-
From: Greg Hennessy [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 13, 2000 2:59 PM
To: [EMAIL PROTECTED]
Subject: Dell smp won't boot
One of my dual cpu dell
It's likely the megaraid driver. Try the megaraid driver that's in the
latest 2.2.18pre.
Thanks,
Matt
-Original Message-
From: Greg Hennessy [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 13, 2000 2:59 PM
To: [EMAIL PROTECTED]
Subject: Dell smp won't boot
One of my dual cpu dell
> I'm still trying to read physical sectors in some partitioning code in
> linux/fs/partitions, and have made progress. Thanks for the pointers on
> set_blocksize(), that helps.
>
My ultimate goal is to read blocks 1, 2-34, n, n-32..n-1, where n is the
number of hardware sectors on the disk.
I'm still trying to read physical sectors in some partitioning code in
linux/fs/partitions, and have made progress. Thanks for the pointers on
set_blocksize(), that helps.
My ultimate goal is to read blocks 1, 2-34, n, n-32..n-1, where n is the
number of hardware sectors on the disk.
> I'm still trying to read physical sectors, and have made progress. Thanks
> for the pointers on set_blocksize(), that seems to do the trick.
>
> However, now I've got another problem. When I read blocks "too quickly",
> I guess the elevator algorithm in ll_rw_block() kicks in and
I'm still trying to read physical sectors, and have made progress. Thanks
for the pointers on set_blocksize(), that seems to do the trick.
However, now I've got another problem. When I read blocks "too quickly",
I guess the elevator algorithm in ll_rw_block() kicks in and re-organizes
my
I'm still trying to read physical sectors, and have made progress. Thanks
for the pointers on set_blocksize(), that seems to do the trick.
However, now I've got another problem. When I read blocks "too quickly", I
guess the elevator algorithm in ll_rw_block() kicks in and re-organizes my
I'm still trying to read physical sectors, and have made progress. Thanks
for the pointers on set_blocksize(), that seems to do the trick.
However, now I've got another problem. When I read blocks "too quickly", I
guess the elevator algorithm in ll_rw_block() kicks in and re-organizes my
Throughout linux/fs/buffer.c, the struct buffer_head member b_blocknr has
integer values put into it, while it's defined to be an unsigned long in
fs.h. For architectures where sizeof(int) != sizeof(long), calls to bread()
could potentially do the wrong thing if the disk has more than 2^41
Throughout linux/fs/buffer.c, the struct buffer_head member b_blocknr has
integer values put into it, while it's defined to be an unsigned long in
fs.h. For architectures where sizeof(int) != sizeof(long), calls to bread()
could potentially do the wrong thing if the disk has more than 2^41
I do appreciate the many responses I've received to my initial query. I'm
glad that there *is* a solution that allows me read/write one hardsector,
and I'll be implementing such in my EFI partition code after the weekend.
As for the issue of understanding a drive's true capacity and
I do appreciate the many responses I've received to my initial query. I'm
glad that there *is* a solution that allows me read/write one hardsector,
and I'll be implementing such in my EFI partition code after the weekend.
As for the issue of understanding a drive's true capacity and
> > > That's what prevents linear raid and proper NTFS support
> from working on
> > > "odd sized" partitions...
> >
> >But the question was about reading from disk, not about reading
> >from partition.
>
Actually, that's next. In EFI, all partitions have a starting LBA and
ending LBA on the
That's what prevents linear raid and proper NTFS support
from working on
"odd sized" partitions...
But the question was about reading from disk, not about reading
from partition.
Actually, that's next. In EFI, all partitions have a starting LBA and
ending LBA on the disk. So, it
There is no APM support in the BIOS on the Dell Inspiron 5000e - it's ACPI
only.
Thanks,
Matt
>
> -Original Message-
> From: Tom Sightler [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 27, 2000 3:59 PM
> To: Linux-Kernel
> Subject: APM Problems
>
> Hi All,
>
> I'm having a
I'm writing some code to grok the Intel EFI GUID Partition Table structures.
To to so, my partition reading code (in fs/partitions) needs to be able to
read one physical sector at a time, particularly the first and last sectors
on the disk. The bread() function ultimately calls ll_rw_block(),
There is no APM support in the BIOS on the Dell Inspiron 5000e - it's ACPI
only.
Thanks,
Matt
-Original Message-
From: Tom Sightler [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 27, 2000 3:59 PM
To: Linux-Kernel
Subject: APM Problems
Hi All,
I'm having a problem
Indeed, my copy of the SCSI 3 SPC-1
(ftp://ftp.t10.org/t10/drafts/spc/spc-r11a.pdf dated 21-Mar-1997) and SPC-2
(ftp://ftp.t10.org/t10/drafts/spc2/spc2r18.pdf dated 21-May-2000) show them
differently. SPC-3 isn't available for download.Anyone have the "final"
copy (if indeed it's not still
Indeed, my copy of the SCSI 3 SPC-1
(ftp://ftp.t10.org/t10/drafts/spc/spc-r11a.pdf dated 21-Mar-1997) and SPC-2
(ftp://ftp.t10.org/t10/drafts/spc2/spc2r18.pdf dated 21-May-2000) show them
differently. SPC-3 isn't available for download.Anyone have the "final"
copy (if indeed it's not still
This patch prevents scsi_ioctl_send_command() from overwriting the SEND
DIAGNOSTICS (Drive Self Test) reserved bits in cmd[1], as found in SCSI-3.
Code provided by Michael Landrus of Dell.
Comments are requested. If there are no objections, Linus and Alan please
apply.
Below are patches to
The KNOWNBUGS file was removed with v1.0.5 as it corrected the fault when
statically linked. You may either statically link, or compile as a module,
your choice.
Thanks,
Matt
-Original Message-
From: Bruce A. Locke [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 9:15 AM
To:
The KNOWNBUGS file was removed with v1.0.5 as it corrected the fault when
statically linked. You may either statically link, or compile as a module,
your choice.
Thanks,
Matt
-Original Message-
From: Bruce A. Locke [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 9:15 AM
To:
This patch prevents scsi_ioctl_send_command() from overwriting the SEND
DIAGNOSTICS (Drive Self Test) reserved bits in cmd[1], as found in SCSI-3.
Code provided by Michael Landrus of Dell.
Comments are requested. If there are no objections, Linus and Alan please
apply.
Below are patches to
The aacraid driver was submitted to Alan Cox, but rejected because it has
too many "NTism's" in it, which are being addressed. Please see the Red Hat
Linux "Pinstripe" beta kernel source RPM for the source code, or contact me
privately.
Sincerely,
Matt Domsch
Dell Enterprise Systems Group
Linux
The aacraid driver was submitted to Alan Cox, but rejected because it has
too many "NTism's" in it, which are being addressed. Please see the Red Hat
Linux "Pinstripe" beta kernel source RPM for the source code, or contact me
privately.
Sincerely,
Matt Domsch
Dell Enterprise Systems Group
Linux
73 matches
Mail list logo
