RE: ppp_mppe+pptp for 2.6.14?
[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 tested this now with a host running kernel 2.6.13 with Matt's > SC_MUST_COMP patch to the kernel and to ppp 2.4.4b1, sending SIGUSR2 > to the pppd while flooding the connection with pings from the server. > > The result is an LCP TermReq from the server to the client, after > which no further data packets appear. All the data packets up to the > LCP TermReq are encrypted. The client sends an LCP TermAck, then > takes down the interface. There's sign of CCP down, in that a CCP > ConfReq appears from the server just after the LCP TermReq. > > I'm not sure this is an adequate test, and will take advice on that. > > Test configuration; > > - server, 2.6.13 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptpd > 1.3.1 > - client, 2.6.12.5 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptp > 1.5.0 > > Client side pppd log fragment; > > local IP address 10.8.0.2 > remote IP address 10.8.0.1 > Script /etc/ppp/ip-up started (pid 5036) Script /etc/ppp/ip-up > finished (pid 5036), status = 0x0 rcvd [LCP TermReq id=0x2 "MPPE > disabled"] LCP terminated by peer (MPPE disabled) Connect time 0.4 > minutes. > Sent 262920 bytes, received 262920 bytes. > Script /etc/ppp/ip-down started (pid 5048) sent [LCP TermAck id=0x2] > rcvd [CCP ConfReq id=0x2 ] Discarded non-LCP > packet when LCP not open Script /etc/ppp/ip-down finished (pid 5048), > status = 0x0 Connection terminated. > Modem hangup This looks good. One more thing I would ask, please repeat with a server that doesn't have the SC_MUST_COMP pppd patch. On SIGUSR2 the unmodified server should still send CCP DOWN to the client, which should start dropping packets. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ppp_mppe+pptp for 2.6.14?
[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 tested this now with a host running kernel 2.6.13 with Matt's SC_MUST_COMP patch to the kernel and to ppp 2.4.4b1, sending SIGUSR2 to the pppd while flooding the connection with pings from the server. The result is an LCP TermReq from the server to the client, after which no further data packets appear. All the data packets up to the LCP TermReq are encrypted. The client sends an LCP TermAck, then takes down the interface. There's sign of CCP down, in that a CCP ConfReq appears from the server just after the LCP TermReq. I'm not sure this is an adequate test, and will take advice on that. Test configuration; - server, 2.6.13 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptpd 1.3.1 - client, 2.6.12.5 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptp 1.5.0 Client side pppd log fragment; local IP address 10.8.0.2 remote IP address 10.8.0.1 Script /etc/ppp/ip-up started (pid 5036) Script /etc/ppp/ip-up finished (pid 5036), status = 0x0 rcvd [LCP TermReq id=0x2 MPPE disabled] LCP terminated by peer (MPPE disabled) Connect time 0.4 minutes. Sent 262920 bytes, received 262920 bytes. Script /etc/ppp/ip-down started (pid 5048) sent [LCP TermAck id=0x2] rcvd [CCP ConfReq id=0x2 mppe +H -M +S -L -D -C] Discarded non-LCP packet when LCP not open Script /etc/ppp/ip-down finished (pid 5048), status = 0x0 Connection terminated. Modem hangup This looks good. One more thing I would ask, please repeat with a server that doesn't have the SC_MUST_COMP pppd patch. On SIGUSR2 the unmodified server should still send CCP DOWN to the client, which should start dropping packets. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Too much memory causes crash when reading/writing to disk
> 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 Dell Linux Solutions www.dell.com/linux #2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)! #3 Unix provider with 18% in the US (Dataquest)! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Too much memory causes crash when reading/writing to disk
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 Dell Linux Solutions www.dell.com/linux #2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)! #3 Unix provider with 18% in the US (Dataquest)! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [OT] Quad-cpu motherboard recommendation
> > 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. Yes, they're > pricey, but they know what they're doing. Thanks for the vote of confidence. :-) Dell PowerEdge 6400 and 6450 servers can have up to 4 Intel Pentium III Xeon 700 or 900MHz CPUs. The 900MHz/2MB cache ones aren't available drop-down on the web page at the moment, but are if you call and ask. www.dell.com/linux, choose PowerEdge 6400, "Buy This System", then call the phone number 1-800-917-DELL listed there, and tell them what you want. Base code 649002 Processors 4P9002M Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Solutions www.dell.com/linux #2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)! #3 Unix provider with 18% in the US (Dataquest)! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [OT] Quad-cpu motherboard recommendation
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. Yes, they're pricey, but they know what they're doing. Thanks for the vote of confidence. :-) Dell PowerEdge 6400 and 6450 servers can have up to 4 Intel Pentium III Xeon 700 or 900MHz CPUs. The 900MHz/2MB cache ones aren't available drop-down on the web page at the moment, but are if you call and ask. www.dell.com/linux, choose PowerEdge 6400, Buy This System, then call the phone number 1-800-917-DELL listed there, and tell them what you want. Base code 649002 Processors 4P9002M Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Solutions www.dell.com/linux #2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)! #3 Unix provider with 18% in the US (Dataquest)! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.[35] + Dell Poweredge 8450 + Oops on boot
> 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 Adaptec SCSI > AMI MegaRaid Single Channel 16mb > Dual Port Intel EtherExpress Pro/100+ Can you check the firmware on the PERC 2/SC? (You claim you tried a different system with a dual-channel, but that would be the PERC 2/DC). There's a bug in the megaraid driver for some versions of the PERC 2/SC firmware which can cause an oops when the megaraid driver loads. It's fixed by upgrading to v3.13 firmware, available by link on http://domsch.com/linux. That *shouldn't* be the problem, as I don't see the megaraid sign-on message, but it could be. Also, the onboard SCSI adapter isn't an Adaptec, it's a Symbios 810. Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Solutions www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.[35] + Dell Poweredge 8450 + Oops on boot
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 Adaptec SCSI AMI MegaRaid Single Channel 16mb Dual Port Intel EtherExpress Pro/100+ Can you check the firmware on the PERC 2/SC? (You claim you tried a different system with a dual-channel, but that would be the PERC 2/DC). There's a bug in the megaraid driver for some versions of the PERC 2/SC firmware which can cause an oops when the megaraid driver loads. It's fixed by upgrading to v3.13 firmware, available by link on http://domsch.com/linux. That *shouldn't* be the problem, as I don't see the megaraid sign-on message, but it could be. Also, the onboard SCSI adapter isn't an Adaptec, it's a Symbios 810. Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Solutions www.dell.com/linux - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi mo dule
> 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 +++ linux/drivers/scsi/fdomain.cWed May 2 07:27:32 2001 @@ -971,7 +971,7 @@ return 0; shpnt->irq = interrupt_level; shpnt->io_port = port_base; - scsi_set_pci_device(shpnt->pci_dev, pdev); + scsi_set_pci_device(shpnt, pdev); shpnt->n_io_port = 0x10; print_banner( shpnt ); Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi module
> > +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 structure beforehand, and NULL afterward. I'll fix and submit a patch, and make sure I didn't make the same mistake elsewhere too. Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi module
+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 structure beforehand, and NULL afterward. I'll fix and submit a patch, and make sure I didn't make the same mistake elsewhere too. Thanks, Matt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi mo dule
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 +++ linux/drivers/scsi/fdomain.cWed May 2 07:27:32 2001 @@ -971,7 +971,7 @@ return 0; shpnt-irq = interrupt_level; shpnt-io_port = port_base; - scsi_set_pci_device(shpnt-pci_dev, pdev); + scsi_set_pci_device(shpnt, pdev); shpnt-n_io_port = 0x10; print_banner( shpnt ); Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] adding PCI bus information to SCSI layer
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 Garzik recommended the IOCTL return pci_dev::slot_name, so now it does, and this simplifies the ioctl greatly. Doug Gilbert recommended wrapping things in #ifdef's, so I created a new CONFIG_SCSI_PCI_INFO define. Patches against 2.4.4-pre6 are available at http://domsch.com/linux/scsi/. linux-2.4.4-pre6-scsi-pci-info-010424.patch - Adds the IOCTL and CONFIG_SCSI_PCI_INFO, and touches a bunch of SCSI drivers. scsimon_243_1_pci-010424.patch - Changes scsimon Makefile and sm_test.c to support this. scsimon_243_1_pci_driver.patch - Changes scsimon.[ch] to support this. When this goes in, I request the assistance of the SCSI driver maintainers. I've changed quite a few drivers, but couldn't easily see how to change a few others. I am bcc'ing the maintainers of drivers I changed or need help from. Drivers that I changed: 3w-.c AM53C974.c advansys.c aic7xxx_old.c atp870u.c cpqfcTSinit.c dmx3191d.c fdomain.c gdth.c ips.c ncr53c8xx.c qla1280.c qlogicfc.c qlogicisp.c sym53c8xx.c tmscsim.c megaraid.c 53c7,8xx.c pci2000.c pci2220i.c Non-trivial drivers that I didn't change, but request their maintainers do so: BusLogic.c aic7xxx.c eata.c eata_dma.c eata_pio.c ini9100u.c inia100.c Drivers I didn't need to change (they're not PCI devices, best as I can tell): NCR53C9x.c NCR53c406a.c aha152x.c aha1542.c aha1740.c esp.c fd_mcs.c ibmmca.c ide-scsi.c imm.c in2000.c mac53c94.c mesh.c ppa.c qlogicfas.c qlogicpti.c sgiwd93.c sim710.c sym53c416.c u14-34f.c ultrastor.c 53c7xx.c a2091.c a3000.c atari_scsi.c dtc.c fcal.c g_NCR5380.c gvp11.c mac_scsi.c mvme147.c pas16.c pluto.c psi240i.c seagate.c sun3_scsi.c t128.c wd7000.c Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] adding PCI bus information to SCSI layer
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 Garzik recommended the IOCTL return pci_dev::slot_name, so now it does, and this simplifies the ioctl greatly. Doug Gilbert recommended wrapping things in #ifdef's, so I created a new CONFIG_SCSI_PCI_INFO define. Patches against 2.4.4-pre6 are available at http://domsch.com/linux/scsi/. linux-2.4.4-pre6-scsi-pci-info-010424.patch - Adds the IOCTL and CONFIG_SCSI_PCI_INFO, and touches a bunch of SCSI drivers. scsimon_243_1_pci-010424.patch - Changes scsimon Makefile and sm_test.c to support this. scsimon_243_1_pci_driver.patch - Changes scsimon.[ch] to support this. When this goes in, I request the assistance of the SCSI driver maintainers. I've changed quite a few drivers, but couldn't easily see how to change a few others. I am bcc'ing the maintainers of drivers I changed or need help from. Drivers that I changed: 3w-.c AM53C974.c advansys.c aic7xxx_old.c atp870u.c cpqfcTSinit.c dmx3191d.c fdomain.c gdth.c ips.c ncr53c8xx.c qla1280.c qlogicfc.c qlogicisp.c sym53c8xx.c tmscsim.c megaraid.c 53c7,8xx.c pci2000.c pci2220i.c Non-trivial drivers that I didn't change, but request their maintainers do so: BusLogic.c aic7xxx.c eata.c eata_dma.c eata_pio.c ini9100u.c inia100.c Drivers I didn't need to change (they're not PCI devices, best as I can tell): NCR53C9x.c NCR53c406a.c aha152x.c aha1542.c aha1740.c esp.c fd_mcs.c ibmmca.c ide-scsi.c imm.c in2000.c mac53c94.c mesh.c ppa.c qlogicfas.c qlogicpti.c sgiwd93.c sim710.c sym53c416.c u14-34f.c ultrastor.c 53c7xx.c a2091.c a3000.c atari_scsi.c dtc.c fcal.c g_NCR5380.c gvp11.c mac_scsi.c mvme147.c pas16.c pluto.c psi240i.c seagate.c sun3_scsi.c t128.c wd7000.c Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH] adding PCI bus information to SCSI layer
> 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
--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH] adding PCI bus information to SCSI layer
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 makes a lot of sense, but I don't want to fan the war over what kind of information should be presented in /proc. :-) Perhaps this can wait for scsimon changes. Doug Gilbert said: > Also ISA adapters are not the only non-PCI adapters, > there are the growing band of pseudo adapters that > may or may not have a PCI bus at the bottom of some > other protocol stack. Alan said: > 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] If I understand multipathing properly, a /dev/mdX device is composed of several block devices, and there are IOCTLs available to list the individual devices that compose a block device. Each multipath component shows up as both /dev/sda and /dev/sdb, but you mount /dev/md0 for your I/Os. BIOSs don't know about multipath devices, they just see the same disk twice and don't know it's really only one disk. Hopefully BIOS only reads the boot sector and jumps, so this is fine. I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and subsystem vendor and device IDs. Equivalent /dev/hdX information is available in /proc/ide/ide0, but not as an IOCTL. It could then be a user-space problem to decompose a mdX into component sdX or hdX devices, and query them appropriately. I'm still not sure if/how to handle: 1) non-PCI-bus devices Here I'm going to need some help. My original design was based on the information presented by EDD 3.0 Rev 5a (www.t13.org), which only presents x86 int13-type devices, and shows them to be either ISA or PCI-based, with the goal of telling the OS which device BIOS thinks is the boot device. Booting off, say, a parallel-port ZIP drive isn't really handled in EDD. 2) Devices like i2o scsi disks The i2o controller can be on any bus type (though I expect most are PCI). The i2o_controller struct has an i2o_hrt member, which does have bus information, but the PCI struct doesn't include subsystem vendor and device fields yet. We'd need to add an IOCTL to retrieve this information, possibly one at a generic i2o level. The EDD 3.0 spec shows that a PCI i2o device returns us a 64-bit Identity Tag, which I'm guessing is the same as a 32-bit target device ID and possibly the TID of the controller too. 3) other block devices (non-SCSI, i2o, or IDE). I haven't investigated these. Doug suggested looking at extending scsimon. This is a fine idea, and I've made proposed changes available at http://domsch.com/linux/scsi/. (Doug may want to clean this up). However, this, like my earlier changes to /proc/scsi/scsi, doesn't actually show the relationship between /dev/sda and a particular PCI controller and SCSI channel,bus,lun tuple. I'd like to see the the PCI device information added to the Scsi_Host structure, the ioctl, and the various PCI SCSI driver changes I mentioned last week. I've removed the changes to /proc/scsi/scsi and rebuilt it against 2.4.4-pre6, available at http://domsch.com/linux/scsi/linux-2.4.4-pre6-scsi-pci-info-noproc.patch If/when this goes in, I'll also request the assistance of all of the SCSI driver maintainers. I've changed quite a few drivers, but couldn't easily see how to change a few others. Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH] adding PCI bus information to SCSI layer
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 makes a lot of sense, but I don't want to fan the war over what kind of information should be presented in /proc. :-) Perhaps this can wait for scsimon changes. Doug Gilbert said: Also ISA adapters are not the only non-PCI adapters, there are the growing band of pseudo adapters that may or may not have a PCI bus at the bottom of some other protocol stack. Alan said: 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] If I understand multipathing properly, a /dev/mdX device is composed of several block devices, and there are IOCTLs available to list the individual devices that compose a block device. Each multipath component shows up as both /dev/sda and /dev/sdb, but you mount /dev/md0 for your I/Os. BIOSs don't know about multipath devices, they just see the same disk twice and don't know it's really only one disk. Hopefully BIOS only reads the boot sector and jumps, so this is fine. I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and subsystem vendor and device IDs. Equivalent /dev/hdX information is available in /proc/ide/ide0, but not as an IOCTL. It could then be a user-space problem to decompose a mdX into component sdX or hdX devices, and query them appropriately. I'm still not sure if/how to handle: 1) non-PCI-bus devices Here I'm going to need some help. My original design was based on the information presented by EDD 3.0 Rev 5a (www.t13.org), which only presents x86 int13-type devices, and shows them to be either ISA or PCI-based, with the goal of telling the OS which device BIOS thinks is the boot device. Booting off, say, a parallel-port ZIP drive isn't really handled in EDD. 2) Devices like i2o scsi disks The i2o controller can be on any bus type (though I expect most are PCI). The i2o_controller struct has an i2o_hrt member, which does have bus information, but the PCI struct doesn't include subsystem vendor and device fields yet. We'd need to add an IOCTL to retrieve this information, possibly one at a generic i2o level. The EDD 3.0 spec shows that a PCI i2o device returns us a 64-bit Identity Tag, which I'm guessing is the same as a 32-bit target device ID and possibly the TID of the controller too. 3) other block devices (non-SCSI, i2o, or IDE). I haven't investigated these. Doug suggested looking at extending scsimon. This is a fine idea, and I've made proposed changes available at http://domsch.com/linux/scsi/. (Doug may want to clean this up). However, this, like my earlier changes to /proc/scsi/scsi, doesn't actually show the relationship between /dev/sda and a particular PCI controller and SCSI channel,bus,lun tuple. I'd like to see the the PCI device information added to the Scsi_Host structure, the ioctl, and the various PCI SCSI driver changes I mentioned last week. I've removed the changes to /proc/scsi/scsi and rebuilt it against 2.4.4-pre6, available at http://domsch.com/linux/scsi/linux-2.4.4-pre6-scsi-pci-info-noproc.patch If/when this goes in, I'll also request the assistance of all of the SCSI driver maintainers. I've changed quite a few drivers, but couldn't easily see how to change a few others. Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH] adding PCI bus information to SCSI layer
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
--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH] adding PCI bus information to SCSI layer
> 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 -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH] adding PCI bus information to SCSI layer
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 -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 and 2GB swap partition limit
> > > 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 partition/file size limitation, and you can have (as currently #defined) 8 swap partitions, you're limited to 16GB swap, which then follows a max of 8GB RAM. We'd like to sell servers with 32GB or 64GB RAM to customers who request such for their applications. Such customers generally have no problem purchasing additional disks to be used for swap, likely on a hardware RAID controller. We've also seen (anecdotal evidence here) cases where a kernel panics, which we believe may have to do with having 0 < swap < 2x RAM. We're investigating further. > Actually the deal is: either use enough swap (about 2x RAM) or use > none at all. If swap space isn't required in all cases, great! We'll encourage the use of swap files as needed, rather than swap partitions. But, if instead you *require* swap = 2x RAM, then the 2GB swap size limitation must go. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 and 2GB swap partition limit
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 partition/file size limitation, and you can have (as currently #defined) 8 swap partitions, you're limited to 16GB swap, which then follows a max of 8GB RAM. We'd like to sell servers with 32GB or 64GB RAM to customers who request such for their applications. Such customers generally have no problem purchasing additional disks to be used for swap, likely on a hardware RAID controller. We've also seen (anecdotal evidence here) cases where a kernel panics, which we believe may have to do with having 0 swap 2x RAM. We're investigating further. Actually the deal is: either use enough swap (about 2x RAM) or use none at all. If swap space isn't required in all cases, great! We'll encourage the use of swap files as needed, rather than swap partitions. But, if instead you *require* swap = 2x RAM, then the 2GB swap size limitation must go. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 and 2GB swap partition limit
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 on each. That's ugly. Is the 2GB per swap partition going to go away any time soon? Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Final aacraid driver for 2.2.x and 2.4.x
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 - No longer calling this "beta". Extensive testing over the past several weeks have not uncovered any driver issues. Distributions, if you're including aacraid support, please update your kernels accordingly. This driver supports the on-board RAID controllers on the Dell PowerEdge 2400, 2450, and 4400 servers, the add-in 4-channel PERC2 card, and the HP NetRAID-4M card. Please join [EMAIL PROTECTED] to discuss this driver, or [EMAIL PROTECTED] to receive future announcements. Information about both lists can be found at http://domsch.com/linux. Special thanks to Jens Axboe for providing the request-size-limiting patch, to Brian Boerner as the main developer of this driver for the past year, and to Adaptec for their continued development support. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Final aacraid driver for 2.2.x and 2.4.x
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 - No longer calling this "beta". Extensive testing over the past several weeks have not uncovered any driver issues. Distributions, if you're including aacraid support, please update your kernels accordingly. This driver supports the on-board RAID controllers on the Dell PowerEdge 2400, 2450, and 4400 servers, the add-in 4-channel PERC2 card, and the HP NetRAID-4M card. Please join [EMAIL PROTECTED] to discuss this driver, or [EMAIL PROTECTED] to receive future announcements. Information about both lists can be found at http://domsch.com/linux. Special thanks to Jens Axboe for providing the request-size-limiting patch, to Brian Boerner as the main developer of this driver for the past year, and to Adaptec for their continued development support. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 and 2GB swap partition limit
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 on each. That's ugly. Is the 2GB per swap partition going to go away any time soon? Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
> 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 through the kernel > to get to the low-level disk IO drivers. This was confirmed by my testing. Reading/writing via /dev/raw/rawX fails exactly the same way as for /dev/[sh]dX. > Accessing /dev/sg ought to work fine, but of course it > places much more load on the application programmer > and removes a ton of kernel safety-nets. I believe using ide-scsi would work, but you must pass "hdc=ide-scsi" at boot time, which isn't a big deal for accessing CD-ROMs, but to be used for arbitrary disks, makes life much more difficult. Now all your IDE disks need to think they're SCSI disks, at least for the boot in which you want to change the partition table. I wouldn't want to suggest to customers that they run this additional layer of abstraction all the time just in case they want to examine and/or change the partition table of just one disk at some time. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
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 through the kernel to get to the low-level disk IO drivers. This was confirmed by my testing. Reading/writing via /dev/raw/rawX fails exactly the same way as for /dev/[sh]dX. Accessing /dev/sg ought to work fine, but of course it places much more load on the application programmer and removes a ton of kernel safety-nets. I believe using ide-scsi would work, but you must pass "hdc=ide-scsi" at boot time, which isn't a big deal for accessing CD-ROMs, but to be used for arbitrary disks, makes life much more difficult. Now all your IDE disks need to think they're SCSI disks, at least for the boot in which you want to change the partition table. I wouldn't want to suggest to customers that they run this additional layer of abstraction all the time just in case they want to examine and/or change the partition table of just one disk at some time. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
> > 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 didn't seem
to work for me.
> I need to read/write the last 512-byte
> sector on an odd-sized disk (IDE and/or SCSI) from user space. Employing
> suggestions from you and l-k, I have implemented two IOCTLs that get/set
the
> blksize_size[MAJOR(dev)][MINOR(dev)] values (via set_blocksize()). In my
> application, I read the hardsector size of a disk device (/dev/sdb) via an
> IOCTL, read the current blksize_size, set it to the hardsector size, and
> then continue, resetting blksize_size back to the original value when
done.
>
> In between, I use fopen64() to open the device /dev/sdb (an odd-sized
disk),
> and lseek64()/fwrite64()/fread64() to write/read the last sector of the
disk
> as reported by the BLKGETSIZE ioctl. The seek succeeds, however, the
> reads/writes fail. Writes fail with "No space left on device". Read
> returns 0, indicating EOF. If I read/write the N-1th sector this way, it
> works just fine. On even-sized disks, this succeeds both with and
> without calling my new IOCTLs, as expected. On odd-sized disks, it
> fails in both cases.
Anton Altaparmakov responded:
> I am sure Andries will correct me if I am wrong but here is
> what I think of the situation at present:
>
> I suspect that you will find the problem in
> linux/fs/block_dev.c functions
> block_write() and block_read() which AFAIK only get called
> when you use
> usermode to read a /dev/* blockdevice as you probably are
> doing. From the
> kernel these functions AFAIK never get called and hence the problem
> doesn't exist (either way I am surprised that it works as looking at
> generic_make_request() there is a check of simillar type and AFAICS it
> would fail as well for the same reason. I probably don't understand
> something there and/or generic_make_request() is not being
> called either,
> as it obviously works, since you have tried it).
>
> In block_write() you find this (lines 58ff in the file in 2.4.0):
> [snip]
> if (blk_size[MAJOR(dev)])
> size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)] <<
> BLOCK_SIZE_BITS) >> blocksize_bits;
> else
> size = INT_MAX;
> while (count>0) {
> if (block >= size)
> return written ? written : -ENOSPC;
> [snip]
>
> As you can see when size is calculated blk_size is multiplied
> by 1024 and
> then divided by 512, effectively blk_size is multiplied by 2.
>
> The effect of this is that size has the lowest bit always
> equal to zero
> and hence it always will be even.
>
> The subsequent check "if (block >= size)" of course is then
> true and we
> return with -ENOSPC straight away.
>
> In block_read() you find this (lines 195ff in the file in 2.4.0):
> [snip]
> if (blk_size[MAJOR(dev)])
> size = (loff_t) blk_size[MAJOR(dev)][MINOR(dev)] <<
> BLOCK_SIZE_BITS;
> else
> size = (loff_t) INT_MAX << BLOCK_SIZE_BITS;
>
> if (offset > size)
> left = 0;
> [snip]
> if (left <= 0)
> return 0;
> [snip]
>
> And again size is equal to blk_size multiplied by 1024 and
> hence always
> will be even.
If this analysis is correct (and I think it is), changing the block size
doesn't actually solve the problem.
I've got no problems requiring any IOCTL (either block-size-changing or just
a read/write last sector) to check that a device isn't in use somehow prior
to making these calls. Changing a disk's partition table while partitions
are actively in use on it isn't generally a good idea. But, fdisk and other
partition table-changing apps don't do this kind of check now IIRC.
Thanks,
Matt
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
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 didn't seem
to work for me.
I need to read/write the last 512-byte
sector on an odd-sized disk (IDE and/or SCSI) from user space. Employing
suggestions from you and l-k, I have implemented two IOCTLs that get/set
the
blksize_size[MAJOR(dev)][MINOR(dev)] values (via set_blocksize()). In my
application, I read the hardsector size of a disk device (/dev/sdb) via an
IOCTL, read the current blksize_size, set it to the hardsector size, and
then continue, resetting blksize_size back to the original value when
done.
In between, I use fopen64() to open the device /dev/sdb (an odd-sized
disk),
and lseek64()/fwrite64()/fread64() to write/read the last sector of the
disk
as reported by the BLKGETSIZE ioctl. The seek succeeds, however, the
reads/writes fail. Writes fail with "No space left on device". Read
returns 0, indicating EOF. If I read/write the N-1th sector this way, it
works just fine. On even-sized disks, this succeeds both with and
without calling my new IOCTLs, as expected. On odd-sized disks, it
fails in both cases.
Anton Altaparmakov responded:
I am sure Andries will correct me if I am wrong but here is
what I think of the situation at present:
I suspect that you will find the problem in
linux/fs/block_dev.c functions
block_write() and block_read() which AFAIK only get called
when you use
usermode to read a /dev/* blockdevice as you probably are
doing. From the
kernel these functions AFAIK never get called and hence the problem
doesn't exist (either way I am surprised that it works as looking at
generic_make_request() there is a check of simillar type and AFAICS it
would fail as well for the same reason. I probably don't understand
something there and/or generic_make_request() is not being
called either,
as it obviously works, since you have tried it).
In block_write() you find this (lines 58ff in the file in 2.4.0):
[snip]
if (blk_size[MAJOR(dev)])
size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)]
BLOCK_SIZE_BITS) blocksize_bits;
else
size = INT_MAX;
while (count0) {
if (block = size)
return written ? written : -ENOSPC;
[snip]
As you can see when size is calculated blk_size is multiplied
by 1024 and
then divided by 512, effectively blk_size is multiplied by 2.
The effect of this is that size has the lowest bit always
equal to zero
and hence it always will be even.
The subsequent check "if (block = size)" of course is then
true and we
return with -ENOSPC straight away.
In block_read() you find this (lines 195ff in the file in 2.4.0):
[snip]
if (blk_size[MAJOR(dev)])
size = (loff_t) blk_size[MAJOR(dev)][MINOR(dev)]
BLOCK_SIZE_BITS;
else
size = (loff_t) INT_MAX BLOCK_SIZE_BITS;
if (offset size)
left = 0;
[snip]
if (left = 0)
return 0;
[snip]
And again size is equal to blk_size multiplied by 1024 and
hence always
will be even.
If this analysis is correct (and I think it is), changing the block size
doesn't actually solve the problem.
I've got no problems requiring any IOCTL (either block-size-changing or just
a read/write last sector) to check that a device isn't in use somehow prior
to making these calls. Changing a disk's partition table while partitions
are actively in use on it isn't generally a good idea. But, fdisk and other
partition table-changing apps don't do this kind of check now IIRC.
Thanks,
Matt
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
> 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 any of the (older) SCSI drivers > have such limitations too. Yes, it's a SCSI driver, not a block driver. Adaptec thought it prudent to try to fix this in their driver rather than try to change the SCSI layer in 2.4.x just now. They expected it would be more difficult getting such a change through validation and into the kernel in a timely manner. -Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
> 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 64KB. Even when scatter/gathered, if the total is >64KB, it chokes. This was just fine for 2.2.x (no one has ever run into this problem there), but the much-improved block layer of 2.4.x throws larger I/Os at the driver. So, the developers at Adaptec are busy trying to add support to break large requests into smaller chunks, and then gather them back together. > I know Alan Cox denied inclusion of the driver due to the > poor nature it was > written for the 2.2 tree. Every post that I have seen so far > has just said > that Adaptec is working on it. So, there are three objectives: 1) Get and maintain a working 2.2.x driver. Yes, Alan Cox doesn't want to merge this into the stock kernel, so until then, it's available separately, and several distributions have picked it up, such as Red Hat Linux 7. 2) Get a working 2.4.x driver. Dell and Adaptec both believe this is critical. Again, we don't expect this driver to make it into the 2.4.x stock kernel, it'll be made available separately to those who want it. This is where development time is being spent today. The best I can say here is "we hope to have something soon". 3) Develop an aacraid driver for both 2.2.x and 2.4.x that will be accepted into the stock kernels. For this to happen, Adaptec engineers will be re-writing the driver from the ground up as a Linux driver. Due to schedule constraints (wanting 2.4.x support sooner rather than later), and because we didn't expect the 64K issue, this has been delayed until 2) is finished. Hopefully the 64K limit will be eradicated then too. I've made a web page http://domsch.com/linux on which I've posted all the 2.2.x aacraid patches, and where I'll post a 2.4.x patch when it's available. I've also created an announcements-only mailing list http://domsch.com/mailman/listinfo/linux-aacraid-announce which you may subscribe to and receive notices of new driver availability. I've created a developers list http://domsch.com/mailman/listinfo/linux-aacraid-devel for discussion of the driver if you wish to contribute. Both the web page and mailing lists will likely be moved to a Dell.com server in the near future. I hope this helps clarify the situation. Thank you for your interest and continued patience. -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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 64KB. Even when scatter/gathered, if the total is 64KB, it chokes. This was just fine for 2.2.x (no one has ever run into this problem there), but the much-improved block layer of 2.4.x throws larger I/Os at the driver. So, the developers at Adaptec are busy trying to add support to break large requests into smaller chunks, and then gather them back together. I know Alan Cox denied inclusion of the driver due to the poor nature it was written for the 2.2 tree. Every post that I have seen so far has just said that Adaptec is working on it. So, there are three objectives: 1) Get and maintain a working 2.2.x driver. Yes, Alan Cox doesn't want to merge this into the stock kernel, so until then, it's available separately, and several distributions have picked it up, such as Red Hat Linux 7. 2) Get a working 2.4.x driver. Dell and Adaptec both believe this is critical. Again, we don't expect this driver to make it into the 2.4.x stock kernel, it'll be made available separately to those who want it. This is where development time is being spent today. The best I can say here is "we hope to have something soon". 3) Develop an aacraid driver for both 2.2.x and 2.4.x that will be accepted into the stock kernels. For this to happen, Adaptec engineers will be re-writing the driver from the ground up as a Linux driver. Due to schedule constraints (wanting 2.4.x support sooner rather than later), and because we didn't expect the 64K issue, this has been delayed until 2) is finished. Hopefully the 64K limit will be eradicated then too. I've made a web page http://domsch.com/linux on which I've posted all the 2.2.x aacraid patches, and where I'll post a 2.4.x patch when it's available. I've also created an announcements-only mailing list http://domsch.com/mailman/listinfo/linux-aacraid-announce which you may subscribe to and receive notices of new driver availability. I've created a developers list http://domsch.com/mailman/listinfo/linux-aacraid-devel for discussion of the driver if you wish to contribute. Both the web page and mailing lists will likely be moved to a Dell.com server in the near future. I hope this helps clarify the situation. Thank you for your interest and continued patience. -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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 any of the (older) SCSI drivers have such limitations too. Yes, it's a SCSI driver, not a block driver. Adaptec thought it prudent to try to fix this in their driver rather than try to change the SCSI layer in 2.4.x just now. They expected it would be more difficult getting such a change through validation and into the kernel in a timely manner. -Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Dell RAID/aacraid support in 2.4
> 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 priority for us, but getting it right is most important. Thanks for buying Dell! -Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Dell RAID/aacraid support in 2.4
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 priority for us, but getting it right is most important. Thanks for buying Dell! -Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: No SCSI Ultra 160 with Adaptec Controller
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 is still necessary. There's a new aic7xxx driver by Justin Gibbs at Adaptec which is now being beta tested which corrects this issue. Something to note, however: the media transfer rate for those disks is at most ~20MB/sec. Therefore, you only exceed the 80MB/sec bus speed if you have more than 4 disks all doing maximum I/O at the same time. Since the PowerApp.web 100 has at most 2 disks internally, you really shouldn't see any significant performance difference. Hope this helps. Thanks for buying Dell! Matt Domsch Dell Linux Systems Group Linux OS Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: No SCSI Ultra 160 with Adaptec Controller
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 is still necessary. There's a new aic7xxx driver by Justin Gibbs at Adaptec which is now being beta tested which corrects this issue. Something to note, however: the media transfer rate for those disks is at most ~20MB/sec. Therefore, you only exceed the 80MB/sec bus speed if you have more than 4 disks all doing maximum I/O at the same time. Since the PowerApp.web 100 has at most 2 disks internally, you really shouldn't see any significant performance difference. Hope this helps. Thanks for buying Dell! Matt Domsch Dell Linux Systems Group Linux OS Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0 oops bdflush
> 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 > without fanfare -- you can, oddly enough, switch consoles > with Alt+F?, but > typing gets no response and all network services have stopped > responding. I've seen exactly this same behavior, on an 8-way Xeon (Dell PowerEdge 8450), with 8GB RAM, but never with either 512MB or 1GB, running 20 instances of a copy-and-compare script using /usr/share/doc from Red Hat Linux 7 as the data source. I see you're using IDE disks, which makes me feel better, as I was testing the new megaraid driver. Magic sysrq works in my case. I've never gotten the oops though, I used magic sysrq to print the IP several times and then tried to look it up. For me, lockup happens in the first few minutes of running this test. I'm happy to try to reproduce it if anyone has suggestions. Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0 oops bdflush
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 without fanfare -- you can, oddly enough, switch consoles with Alt+F?, but typing gets no response and all network services have stopped responding. I've seen exactly this same behavior, on an 8-way Xeon (Dell PowerEdge 8450), with 8GB RAM, but never with either 512MB or 1GB, running 20 instances of a copy-and-compare script using /usr/share/doc from Red Hat Linux 7 as the data source. I see you're using IDE disks, which makes me feel better, as I was testing the new megaraid driver. Magic sysrq works in my case. I've never gotten the oops though, I used magic sysrq to print the IP several times and then tried to look it up. For me, lockup happens in the first few minutes of running this test. I'm happy to try to reproduce it if anyone has suggestions. Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid
> 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 in the Red Hat Linux 7 kernel 2.2.16-22. I'd recommend using that kernel (if not the whole distro), or at least you can grab the aacraid patches from the kernel source RPM for that kernel from ftp.redhat.com or one of its mirrors. Be sure to grab all the *aacraid* patches from the /usr/src/redhat/SOURCES directory after installing the kernel source RPM, and apply those patches to your own kernel. It's is known to work with 2.2.18 kernels. Work on porting to the 2.4 kernel is not yet complete. Thanks for buying Dell! Matt Domsch Dell Enterprise Systems Group Linux Development Team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid
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 in the Red Hat Linux 7 kernel 2.2.16-22. I'd recommend using that kernel (if not the whole distro), or at least you can grab the aacraid patches from the kernel source RPM for that kernel from ftp.redhat.com or one of its mirrors. Be sure to grab all the *aacraid* patches from the /usr/src/redhat/SOURCES directory after installing the kernel source RPM, and apply those patches to your own kernel. It's is known to work with 2.2.18 kernels. Work on porting to the 2.4 kernel is not yet complete. Thanks for buying Dell! Matt Domsch Dell Enterprise Systems Group Linux Development Team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pci_read_bases trivial fixup
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 linux/drivers/pci/pci.c.orig linux/drivers/pci/pci.c
--- linux/drivers/pci/pci.c.origTue Dec 5 07:49:28 2000
+++ linux/drivers/pci/pci.c Tue Dec 5 07:49:36 2000
@@ -540,7 +540,7 @@
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int
rom)
{
unsigned int pos, reg, next;
- u32 l, sz;
+ u32 l, sz, tmp;
struct resource *res;
for(pos=0; poshttp://www.tux.org/lkml/
[PATCH] pci_read_bases trivial fixup
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 linux/drivers/pci/pci.c.orig linux/drivers/pci/pci.c
--- linux/drivers/pci/pci.c.origTue Dec 5 07:49:28 2000
+++ linux/drivers/pci/pci.c Tue Dec 5 07:49:36 2000
@@ -540,7 +540,7 @@
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int
rom)
{
unsigned int pos, reg, next;
- u32 l, sz;
+ u32 l, sz, tmp;
struct resource *res;
for(pos=0; poshowmany; pos = next) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: PROBLEM: DELL PERC/Megaraid RAID driver in Linux 2.2.18pre17 hang
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, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: PROBLEM: DELL PERC/Megaraid RAID driver in Linux 2.2.18pre17 hang
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, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: QLOGIC Fibre Channel init
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]] Sent: Thursday, October 26, 2000 7:23 AM Cc: [EMAIL PROTECTED] Subject: Re: QLOGIC Fibre Channel init > On Thu, 26 Oct 2000, Klaus Naumann wrote: > > > I was having some little trouble with the QLOGIC Fibre Channel SCSI > > cards. > > The issue is, that I have a box with an internal SCSI controller/disk > > and a QLOGIC card which is connected to an external RAID. The probelm > > is, that the internal disk is my root disk but is the second in the > > chain (sdb) after bootup. This gives a lot of problems, because it's > > impossible to get the system to boot (LILO isn't working). > > Since I've modified the hosts.c it's working perfectly (at least the > > order is better now). Patch is attached. > > Can anyone give a comment on that please ? > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] EFI GUID Partition Table support
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 helping me to understand the kernel block device layer. Please direct any feedback you have with about code to me. Thanks, Matt Domsch Dell Enterprise Systems Group Linux Development Team <> linux-2.4.0-test9-efigpt-001025.patch
RE: Dell smp won't boot
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 server running 2.2.15 has stopped booting. It gets part way through the boot process and rints wait_oin_bh, cpu 1 irq: 0 [0 0] bh: 1 [1 0] <[c010aefd]> <[c0119ecf]> <[c011a029]> <[c0113ad0]> <[c010933c]> and repeats. Might this be a software problem, or should I simply call in for a tech support person to schedule a site visit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Dell smp won't boot
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 server running 2.2.15 has stopped booting. It gets part way through the boot process and rints wait_oin_bh, cpu 1 irq: 0 [0 0] bh: 1 [1 0] [c010aefd] [c0119ecf] [c011a029] [c0113ad0] [c010933c] and repeats. Might this be a software problem, or should I simply call in for a tech support person to schedule a site visit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
multiple bread()s causes oops
> 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. However, when I sequentially read
blocks, I get the oopses below. (kernel 2.4.0-test9-final on i686 SMP and
UP, IA-64 SMP fails similarly.)
dev is a SCSI disk, /dev/sdd or the like.
set_blocksize(dev, 512)
bread(dev, 1, 512) - succeeds. - Use the data to figure out how many more
blocks to read, and where they are.
bread(dev, 2, 512) - succeeds.
bread(dev, 3, 512) - succeeds.
bread(dev, 4, 512) - succeeds (most of the time).
bread(dev, 5, 512) - oops, kernel dereferences NULL.
If I insert a delay between the breads {while (jiffies < j + HZ)
schedule();}, I can read more blocks, but it fails after 9-10 blocks rather
than 4-5. Or, if I insert a delay in bread() between calling ll_rw_block()
and wait_on_block(), it fails after 9-10 blocks.
It seems that the I/O completion is actually causing the NULL dereference.
It's neither in ll_rw_block() or wait_on_block() when it bombs, from what I
can tell.
I'm not acquiring any locks in my code before calling bread(). Should I?
I've tried getting the BKL first, no difference.
This has tripped me up for about a week now, so I'd really appreciate any
pointers.
Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team
SMP oops.txt
Unable to handle kernel NULL pointer dereference at virtual address
*pde = 37b11001
Oops:
CPU:0
EIP:0010:[<>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: c211dba0 ecx: edx: c029bfa8
esi: edi: 0001 ebp: 001f esp: c029bf60
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c029b000)
Stack: c010d4c0 001f c029bfa8 c029bfa8 c02d8be0 001f
c211dba0
c010d6c1 001f c029bfa8 c211dba0 c029a000 c0109bf0
c029a000
e000 c010bbf8 c029a000 c029a000 c0109bf0 c029a000
e000
Call Trace: [] [] [] [] []
[] []
Code: Bad EIP value.
>>EIP; Before first symbol
Trace; c010d4c0
Trace; c010d6c1
Trace; c0109bf0
Trace; c010bbf8
Trace; c0109bf0
Trace; c0109c1e
Trace; c0109ca2
UP oops.txt
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /root/linux/System.map (specified)
Warning (expand_objects): object /lib/aic7xxx.o for module aic7xxx has
changed since load
Unable to handle kernel paging request at virtual address fffc
c016d49b
*pde = 1063
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: ebx: ecx: edx:
esi: edi: 021c ebp: c1ef52e0 esp: f7adb77c
ds: 0018 es: 0018 ss: 0018
Process insmod (pid: 7, stackpage=f7adb000)
Stack: 0001 c1ef52e0 c025cc00 c016d68c c1ef52e0
f7fba870
0002 c02ae580 c01204da c1ef52e0 c02c6600
c011d6cc
c02c6600 c011d5d8 0001 0001 c02ae5a0 000e c011d4dd
c02ae5a0
Call Trace: [] [] [] [] []
[] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[]
Code: 8b 0c 82 89 d8 31 cf 8b 4d 18 01 c8 21 f0 8b 0c 82 89 d8 31
>>EIP; c016d49b<=
Trace; c016d68c
Trace; c01204da
Trace; c011d6cc
Trace; c011d5d8
Trace; c011d4dd
Trace; c010bc81
Trace; c010a8a0
Trace; c0119e9a
Trace; c014e8e7
Trace; c021bd24
Trace; c014ea8c (this is my function, bread + extra
printks)
Trace; c021bede
Trace; c0119ea9
Trace; c014ebb4 (this is my function, calls my_bread())
Trace; c014ed6b (These next 4 are my
functions too, they don't touch the disk at all).
Trace; c014edf7
Trace; c014ee79
Trace; c014f14d
Trace; f881abcd <[aic7xxx]aic7xxx_build_negotiation_cmnd+1cd/1e0>
Trace; f881a5a0 <[aic7xxx]aic7xxx_negotiation_complete+0/460>
Trace; f881ad58 <[aic7xxx]aic7xxx_buildscb+178/340>
Trace; f881b053 <[aic7xxx]aic7xxx_queue+133/140>
Trace; c019b7e1
Trace; c01a2cec
Trace; c0117751
Trace; c0250040
Trace; c01209c0
Trace; c0120cd3
Trace; c0120876
Trace; c0120a84
Trace; c011d6cc
Trace; c011d5d8
Trace; c011d4dd
Trace; c010bc81
Trace; c010a8a0
Trace; c0119ea9
Trace; c0132040
Trace; c0217440
Trace; c014f371 (this is my function, called by
msdos_partition())
Trace; c014f383
Trace; c014e5f0
Trace; c0119ea9
Trace; c014e04c
Trace; c01a69fa
Trace; c014e134
Trace; c01a710a
Trace; f8825260 <[aic7xxx]driver_template+0/6b>
Trace; c019cf30
Trace; f8804000 <_end+38527350/385273b0>
Trace; f8804050 <_end+385273a0/385273b0>
Trace; f881e257
multiple bread()s causes oops
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. However, when I sequentially read
blocks, I get the oopses below. (kernel 2.4.0-test9-final on i686 SMP and
UP, IA-64 SMP fails similarly.)
dev is a SCSI disk, /dev/sdd or the like.
set_blocksize(dev, 512)
bread(dev, 1, 512) - succeeds. - Use the data to figure out how many more
blocks to read, and where they are.
bread(dev, 2, 512) - succeeds.
bread(dev, 3, 512) - succeeds.
bread(dev, 4, 512) - succeeds (most of the time).
bread(dev, 5, 512) - oops, kernel dereferences NULL.
If I insert a delay between the breads {while (jiffies j + HZ)
schedule();}, I can read more blocks, but it fails after 9-10 blocks rather
than 4-5. Or, if I insert a delay in bread() between calling ll_rw_block()
and wait_on_block(), it fails after 9-10 blocks.
It seems that the I/O completion is actually causing the NULL dereference.
It's neither in ll_rw_block() or wait_on_block() when it bombs, from what I
can tell.
I'm not acquiring any locks in my code before calling bread(). Should I?
I've tried getting the BKL first, no difference.
This has tripped me up for about a week now, so I'd really appreciate any
pointers.
Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team
SMP oops.txt
Unable to handle kernel NULL pointer dereference at virtual address
*pde = 37b11001
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: c211dba0 ecx: edx: c029bfa8
esi: edi: 0001 ebp: 001f esp: c029bf60
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c029b000)
Stack: c010d4c0 001f c029bfa8 c029bfa8 c02d8be0 001f
c211dba0
c010d6c1 001f c029bfa8 c211dba0 c029a000 c0109bf0
c029a000
e000 c010bbf8 c029a000 c029a000 c0109bf0 c029a000
e000
Call Trace: [c010d4c0] [c010d6c1] [c0109bf0] [c010bbf8] [c0109bf0]
[c0109c1e] [c0109ca2]
Code: Bad EIP value.
EIP; Before first symbol
Trace; c010d4c0 handle_IRQ_event+60/90
Trace; c010d6c1 do_IRQ+a1/100
Trace; c0109bf0 default_idle+0/40
Trace; c010bbf8 ret_from_intr+0/20
Trace; c0109bf0 default_idle+0/40
Trace; c0109c1e default_idle+2e/40
Trace; c0109ca2 cpu_idle+52/70
UP oops.txt
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /root/linux/System.map (specified)
Warning (expand_objects): object /lib/aic7xxx.o for module aic7xxx has
changed since load
Unable to handle kernel paging request at virtual address fffc
c016d49b
*pde = 1063
Oops:
CPU:0
EIP:0010:[c016d49b]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: ebx: ecx: edx:
esi: edi: 021c ebp: c1ef52e0 esp: f7adb77c
ds: 0018 es: 0018 ss: 0018
Process insmod (pid: 7, stackpage=f7adb000)
Stack: 0001 c1ef52e0 c025cc00 c016d68c c1ef52e0
f7fba870
0002 c02ae580 c01204da c1ef52e0 c02c6600
c011d6cc
c02c6600 c011d5d8 0001 0001 c02ae5a0 000e c011d4dd
c02ae5a0
Call Trace: [c016d68c] [c01204da] [c011d6cc] [c011d5d8] [c011d4dd]
[c010bc81] [c010a8a0]
[c0119e9a] [c014e8e7] [c021bd24] [c014ea8c] [c021bede]
[c0119ea9] [c014ebb4] [c014ed6b]
[c014edf7] [c014ee79] [c014f14d] [f881abcd] [f881a5a0]
[f881ad58] [f881b053] [c019b7e1]
[c01a2cec] [c0117751] [c0250040] [c01209c0] [c0120cd3]
[c0120876] [c0120a84] [c011d6cc]
[c011d5d8] [c011d4dd] [c010bc81] [c010a8a0] [c0119ea9]
[c0132040] [c0217440] [c014f371]
[c014f383] [c014e5f0] [c0119ea9] [c014e04c] [c01a69fa]
[c014e134] [c01a710a] [f8825260]
[c019cf30] [f8804000] [f8804050] [f881e257] [f8825260]
[f8825260] [c011a7d2] [f8804048]
[c010a7f7]
Code: 8b 0c 82 89 d8 31 cf 8b 4d 18 01 c8 21 f0 8b 0c 82 89 d8 31
EIP; c016d49b add_entropy_words+5b/d0 =
Trace; c016d68c batch_entropy_process+3c/c0
Trace; c01204da tqueue_bh+3a/50
Trace; c011d6cc bh_action+1c/60
Trace; c011d5d8 tasklet_hi_action+38/60
Trace; c011d4dd do_softirq+5d/80
Trace; c010bc81 do_IRQ+a1/b0
Trace; c010a8a0 ret_from_intr+0/20
Trace; c0119e9a printk+15a/180
Trace; c014e8e7 unparse_buffer_head+27/140
Trace; c021bd24 tvecs+7e40/fba8
Trace; c014ea8c my_bread+8c/c0(this is my function, bread + extra
printks)
Trace; c021bede tvecs+7ffa/fba8
Trace; c0119ea9 printk+169/180
Trace; c014ebb4 ReadLBA+f4/170 (this is my function, calls my_bread())
Trace; c014ed6b ReadGuidPartitionEntries+4b/70 (These next 4 are my
functions too, they don't touch the disk at all).
Trace;
ll_rw_block() changes buffer_heads to NULL?
> 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 buffer_head structures? I'm trying to read 1 sector (which succeeds
> just fine), then 32 sectors, one at a time, which fails.
> ReadLBA(2) - OK
> ReadLBA(3) - OK
> ReadLBA(4) - fails, kernel dereferences NULL,
>
> All calls to getblk() succeed, and none of my buffer heads are NULL. I
> pass this array to ll_rw_block(), which rewrites my array, leaving most of
> my buffer_head pointers as NULL. So, I thought, that for each buffer head
> that isn't NULL, maybe my next buffer head is in b_reqnext, but nope.
> It's NULL too.
>
FWIW, this is the second version of my function. Originally, I just looped,
calling bread(dev, lba++, blocksize), which oops in the same way. Both
IA-32 and IA-64, kernel 2.4.0-test9.
> TIA for your help.
> -Matt
>
> struct buffer_head ** my_bread(kdev_t dev, u64 lba, u64 blockstoread)
> {
> struct buffer_head **bh, *thisbh;
>
> unsigned int blocksize = get_hardblocksize(dev);
> unsigned int i;
> if (!blocksize) blocksize = 512;
> printk(KERN_INFO "about to getblk %d blocks\n", blockstoread);
>
> bh = kmalloc(GFP_KERNEL, blockstoread * sizeof(struct buffer_head *));
> if (!bh) return NULL;
>
> for (i=0; i bh[i] = getblk(dev, lba+i, blocksize);
> if (!bh[i]) {
> printk(KERN_WARNING, "getblk(lba=%x) failed.\n", lba);
> }
> }
>
> /* at this point, none of the bh[i]s are NULL. */
>
> ll_rw_block(READ, blockstoread, bh);
>
> /* now, all but the first 3 bh[i]s are NULL, and all bh[i]->b_reqnext ==
> NULL */
>
> /* Walk the chain */
> for (i=0; i if (!bh[i]) continue;
>
> thisbh = bh[i];
> do {
> wait_on_buffer(thisbh);
> if (!buffer_uptodate(thisbh)) {
> printk(KERN_WARNING "bh is not uptodate after waiting!\n");
> }
> thisbh = thisbh->b_reqnext;
> if (thisbh) printk(KERN_INFO "my_bread walking the chain...\n");
> } while (thisbh);
> }
>
> return bh;
> }
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ll_rw_block() changes buffer_heads to NULL?
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 buffer_head structures? I'm trying to read 1 sector (which succeeds
just fine), then 32 sectors, one at a time, which fails.
ReadLBA(2) - OK
ReadLBA(3) - OK
ReadLBA(4) - fails, kernel dereferences NULL,
All calls to getblk() succeed, and none of my buffer heads are NULL. I
pass this array to ll_rw_block(), which rewrites my array, leaving most of
my buffer_head pointers as NULL. So, I thought, that for each buffer head
that isn't NULL, maybe my next buffer head is in b_reqnext, but nope.
It's NULL too.
FWIW, this is the second version of my function. Originally, I just looped,
calling bread(dev, lba++, blocksize), which oops in the same way. Both
IA-32 and IA-64, kernel 2.4.0-test9.
TIA for your help.
-Matt
struct buffer_head ** my_bread(kdev_t dev, u64 lba, u64 blockstoread)
{
struct buffer_head **bh, *thisbh;
unsigned int blocksize = get_hardblocksize(dev);
unsigned int i;
if (!blocksize) blocksize = 512;
printk(KERN_INFO "about to getblk %d blocks\n", blockstoread);
bh = kmalloc(GFP_KERNEL, blockstoread * sizeof(struct buffer_head *));
if (!bh) return NULL;
for (i=0; iblockstoread; i++) {
bh[i] = getblk(dev, lba+i, blocksize);
if (!bh[i]) {
printk(KERN_WARNING, "getblk(lba=%x) failed.\n", lba);
}
}
/* at this point, none of the bh[i]s are NULL. */
ll_rw_block(READ, blockstoread, bh);
/* now, all but the first 3 bh[i]s are NULL, and all bh[i]-b_reqnext ==
NULL */
/* Walk the chain */
for (i=0; iblockstoread; i++) {
if (!bh[i]) continue;
thisbh = bh[i];
do {
wait_on_buffer(thisbh);
if (!buffer_uptodate(thisbh)) {
printk(KERN_WARNING "bh is not uptodate after waiting!\n");
}
thisbh = thisbh-b_reqnext;
if (thisbh) printk(KERN_INFO "my_bread walking the chain...\n");
} while (thisbh);
}
return bh;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
No Subject
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
buffer_head structures?
ReadLBA(2) - OK
ReadLBA(3) - OK
ReadLBA(4) - fails, kernel dereferences NULL,
All calls to getblk() succeed, and none of my buffer heads are NULL. I pass
this array to ll_rw_block(), which rewrites my array, leaving most of my
buffer_head pointers as NULL. So, I thought, that for each buffer head that
isn't NULL, maybe my next buffer head is in b_reqnext, but nope. It's NULL
too.
oops and my function are below. FWIW, this is the second version of my
function. Originally, I just looped, calling bread(dev, lba++, blocksize),
which oops in the same way. Both IA-32 and IA-64, kernel 2.4.0-test9.
TIA for your help.
-Matt
Unable to handle kernel NULL pointer dereference at virtual address
*pde = 37b11001
Oops:
CPU:0
EIP:0010:[<>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: c211dba0 ecx: edx: c029bfa8
esi: edi: 0001 ebp: 001f esp: c029bf60
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c029b000)
Stack: c010d4c0 001f c029bfa8 c029bfa8 c02d8be0 001f
c211dba0
c010d6c1 001f c029bfa8 c211dba0 c029a000 c0109bf0
c029a000
e000 c010bbf8 c029a000 c029a000 c0109bf0 c029a000
e000
Call Trace: [] [] [] [] []
[] []
[] [] []
Code: Bad EIP value.
>>EIP; Before first symbol
Trace; c010d4c0
Trace; c010d6c1
Trace; c0109bf0
Trace; c010bbf8
Trace; c0109bf0
Trace; c0100018
Trace; c0109c1e
Trace; c0109ca2
Trace; c0105000
Trace; c01001d0
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
struct buffer_head ** my_bread(kdev_t dev, u64 lba, u64 blockstoread)
{
struct buffer_head **bh, *thisbh;
unsigned int blocksize = get_hardblocksize(dev);
unsigned int i;
if (!blocksize) blocksize = 512;
printk(KERN_INFO "about to getblk %d blocks\n", blockstoread);
bh = kmalloc(GFP_KERNEL, blockstoread * sizeof(struct buffer_head *));
if (!bh) return NULL;
for (i=0; ib_reqnext ==
NULL */
/* Walk the chain */
for (i=0; ib_reqnext;
if (thisbh) printk(KERN_INFO "my_bread walking the chain...\n");
} while (thisbh);
}
return bh;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
No Subject
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
buffer_head structures?
ReadLBA(2) - OK
ReadLBA(3) - OK
ReadLBA(4) - fails, kernel dereferences NULL,
All calls to getblk() succeed, and none of my buffer heads are NULL. I pass
this array to ll_rw_block(), which rewrites my array, leaving most of my
buffer_head pointers as NULL. So, I thought, that for each buffer head that
isn't NULL, maybe my next buffer head is in b_reqnext, but nope. It's NULL
too.
oops and my function are below. FWIW, this is the second version of my
function. Originally, I just looped, calling bread(dev, lba++, blocksize),
which oops in the same way. Both IA-32 and IA-64, kernel 2.4.0-test9.
TIA for your help.
-Matt
Unable to handle kernel NULL pointer dereference at virtual address
*pde = 37b11001
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: c211dba0 ecx: edx: c029bfa8
esi: edi: 0001 ebp: 001f esp: c029bf60
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c029b000)
Stack: c010d4c0 001f c029bfa8 c029bfa8 c02d8be0 001f
c211dba0
c010d6c1 001f c029bfa8 c211dba0 c029a000 c0109bf0
c029a000
e000 c010bbf8 c029a000 c029a000 c0109bf0 c029a000
e000
Call Trace: [c010d4c0] [c010d6c1] [c0109bf0] [c010bbf8] [c0109bf0]
[c0100018] [c0109c1e]
[c0109ca2] [c0105000] [c01001d0]
Code: Bad EIP value.
EIP; Before first symbol
Trace; c010d4c0 handle_IRQ_event+60/90
Trace; c010d6c1 do_IRQ+a1/100
Trace; c0109bf0 default_idle+0/40
Trace; c010bbf8 ret_from_intr+0/20
Trace; c0109bf0 default_idle+0/40
Trace; c0100018 startup_32+18/cc
Trace; c0109c1e default_idle+2e/40
Trace; c0109ca2 cpu_idle+52/70
Trace; c0105000 empty_bad_page+0/1000
Trace; c01001d0 L6+0/2
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
struct buffer_head ** my_bread(kdev_t dev, u64 lba, u64 blockstoread)
{
struct buffer_head **bh, *thisbh;
unsigned int blocksize = get_hardblocksize(dev);
unsigned int i;
if (!blocksize) blocksize = 512;
printk(KERN_INFO "about to getblk %d blocks\n", blockstoread);
bh = kmalloc(GFP_KERNEL, blockstoread * sizeof(struct buffer_head *));
if (!bh) return NULL;
for (i=0; iblockstoread; i++) {
bh[i] = getblk(dev, lba+i, blocksize);
if (!bh[i]) {
printk(KERN_WARNING, "getblk(lba=%x) failed.\n", lba);
}
}
/* at this point, none of the bh[i]s are NULL. */
ll_rw_block(READ, blockstoread, bh);
/* now, all but the first 3 bh[i]s are NULL, and all bh[i]-b_reqnext ==
NULL */
/* Walk the chain */
for (i=0; iblockstoread; i++) {
if (!bh[i]) continue;
thisbh = bh[i];
do {
wait_on_buffer(thisbh);
if (!buffer_uptodate(thisbh)) {
printk(KERN_WARNING "bh is not uptodate after waiting!\n");
}
thisbh = thisbh-b_reqnext;
if (thisbh) printk(KERN_INFO "my_bread walking the chain...\n");
} while (thisbh);
}
return bh;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
buffer_head.b_blocknr is unsigned long, not int
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 blocks (2 TB or more, depending on block size). Before hunting down all the places where b_blocknr gets an integer put in it, and making a patch, I thought I'd ask first if there's a good reason why it's done this way. In a few places, values such as -1 and -1000 are put there as dummy values, so don't hurt anything. Are there other reasons? Thanks, Matt Domsch Dell Enterprise Systems Group Linux Development Team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
buffer_head.b_blocknr is unsigned long, not int
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 blocks (2 TB or more, depending on block size). Before hunting down all the places where b_blocknr gets an integer put in it, and making a patch, I thought I'd ask first if there's a good reason why it's done this way. In a few places, values such as -1 and -1000 are put there as dummy values, so don't hurt anything. Are there other reasons? Thanks, Matt Domsch Dell Enterprise Systems Group Linux Development Team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: reading 1 hardsector size, not one block size
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 capabilities, as opposed to what it "normally" returns, the two issues are orthogonal. >From a hardware manufacturer's point of view, for diagnostics, support, and other reasons, it would be nice to be able to access all capabilities that a specific disk can provide. Accessing data beyond the reported last sector for the purposes of partition table backup, diagnostic information, etc. could be very valuable. Do I think that access to this "extra" disk space necessarily should be the job of any file system layer? No. Should it be the job of the block layer, to abstract the difference between SCSI and IDE, probably, so long as the IDE and SCSI drivers can present the same interface for accessing the same feature on both types of disks. In cases where IDE and SCSI disks differ, then either a) the block layer supports one, and stub no-ops the other, or b) it's left up to the IDE and SCSI drivers to present that feature. From user-space, I'd prefer that a) be implemented, because I don't care if it's a SCSI or IDE disk necessarily, but I'd want the same behavior from either. Clearly this part of the discussion needs to be held-over until 2.5. Again, thanks for everyone's comments. I'll be submitting a patch to enable the EFI stuff in the near future. Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: reading 1 hardsector size, not one block size
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 capabilities, as opposed to what it "normally" returns, the two issues are orthogonal. From a hardware manufacturer's point of view, for diagnostics, support, and other reasons, it would be nice to be able to access all capabilities that a specific disk can provide. Accessing data beyond the reported last sector for the purposes of partition table backup, diagnostic information, etc. could be very valuable. Do I think that access to this "extra" disk space necessarily should be the job of any file system layer? No. Should it be the job of the block layer, to abstract the difference between SCSI and IDE, probably, so long as the IDE and SCSI drivers can present the same interface for accessing the same feature on both types of disks. In cases where IDE and SCSI disks differ, then either a) the block layer supports one, and stub no-ops the other, or b) it's left up to the IDE and SCSI drivers to present that feature. From user-space, I'd prefer that a) be implemented, because I don't care if it's a SCSI or IDE disk necessarily, but I'd want the same behavior from either. Clearly this part of the discussion needs to be held-over until 2.5. Again, thanks for everyone's comments. I'll be submitting a patch to enable the EFI stuff in the near future. Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: reading 1 hardsector size, not one block size
> > > 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 would be easy to have an "odd sized" partition. In my current case, I would care about reading/writing to a FAT file system on that partition, or potentially any type file system. My fdisk enhancement will guarantee that only "even sized" partitions are created, but if someone else's partitioning program weren't so careful, I'd still have to live with the consequences. If I know a partition has a FAT file system on it, may I leave the block size == hard sector size, and mount it? Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: reading 1 hardsector size, not one block size
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 would be easy to have an "odd sized" partition. In my current case, I would care about reading/writing to a FAT file system on that partition, or potentially any type file system. My fdisk enhancement will guarantee that only "even sized" partitions are created, but if someone else's partitioning program weren't so careful, I'd still have to live with the consequences. If I know a partition has a FAT file system on it, may I leave the block size == hard sector size, and mount it? Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: APM Problems
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 related to APM on my Dell Inspiron 5000e (just > arrived a few > days ago). I installed Redhat 7.0 and upon reboot was immediately > greeted by > scrolling oops screens. The system did boot on up and upon further > examintation > I found the errors were caused by the attempt to start apmd. Acutally, > any > access to /proc/apm would generate a non-fatal oops > (general protection > fault). > > I compiled a standard 2.2.17 and 2.4.0-test9-pre7 but both experience > exactly the > same symptom, any access to /proc/apm and you get an oops. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reading 1 hardsector size, not one block size
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(), which checks that my read size is the same as the block size, which is 1024 for a SCSI disk, while the physical sector size is 512 bytes. The EFI Spec calls for reading/writing on the physical block size. In the case of reading the first sector, I could read 2 sectors and throw away the bottom half. In the case of reading the last sector, I have to read the last 2 sectors and throw away the top half (assuming the disk has an even number of 512-byte sectors). In the case of reading exactly one sector from the middle of the disk, it's similar to either the first or second case. To read say 32 sectors anywhere on the disk, I have to do 1024-byte aligned bread()s, possibly doing an unaligned first block, aligned middle, and unaligned last block. Is there an easier method? Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: APM Problems
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 related to APM on my Dell Inspiron 5000e (just arrived a few days ago). I installed Redhat 7.0 and upon reboot was immediately greeted by scrolling oops screens. The system did boot on up and upon further examintation I found the errors were caused by the attempt to start apmd. Acutally, any access to /proc/apm would generate a non-fatal oops (general protection fault). I compiled a standard 2.2.17 and 2.4.0-test9-pre7 but both experience exactly the same symptom, any access to /proc/apm and you get an oops. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Retract - [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTIC S reserved bits
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 in draft state)? SCSI1 - byte 1 bits 5-7 are the LUN address SCSI2 - byte 1 bits 5-7 are the LUN address SCSI3 SPC-1 - byte 1 bits 5-7 are marked "reserved" for all commands SCSI3 SPC-2 - byte 1 bits 5-7 are now used for self test codes for the SEND DIAGNOSTIC command, "reserved" for all other commands that I could see. Maybe the proper logic would be to switch ioctl_send_command() functions based on the version field in the INQUIRY data as you suggest, and then in the SCSI3 case, handle SEND_DIAGNOSTIC separately? I hereby retract my patch until a better solution is agreed upon that doesn't break SCSI backward compatability. Thanks, Matt -Original Message- From: Guest section DW [mailto:[EMAIL PROTECTED]] Sent: Monday, September 18, 2000 3:57 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTIC S reserved bits On Mon, Sep 18, 2000 at 11:31:09AM -0500, [EMAIL PROTECTED] wrote: > 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 kernels 2.2.18-pre8 and 2.4.0-test9-pre1. > -cmd[1] = ( cmd[1] & 0x1f ) | (dev->lun << 5); > +if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND DIAGNOSTICS > reserved bits > + cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5); I am a bit surprised: why only SEND DIAGNOSTICS? If I am not mistaken SCSI-1 used this 3-bit LUN field in all commands, and SCSI-2 still does, but the standard says: 7.2.2 Logical unit number ... NOTICE: The logical unit number field is included in the command descriptor block for compatibility with some SCSI-1 devices. This field may be reclaimed in SCSI-3. and SCSI-3 calls these bits "reserved", for all commands, also for SEND DIAGNOSTICS. So: (i) I don't see what is special with SEND DIAGNOSTICS. Maybe for SCSI-3 the lun should never be inserted. (ii) On the other hand, for SCSI-1 the lun should always be inserted. Once these bits really get used again (are there already examples of a new use?) I suppose we should introduce a new SCSI3_IOCTL_SEND_COMMAND instead of changing SCSI_IOCTL_SEND_COMMAND. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Retract - [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTIC S reserved bits
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 in draft state)? SCSI1 - byte 1 bits 5-7 are the LUN address SCSI2 - byte 1 bits 5-7 are the LUN address SCSI3 SPC-1 - byte 1 bits 5-7 are marked "reserved" for all commands SCSI3 SPC-2 - byte 1 bits 5-7 are now used for self test codes for the SEND DIAGNOSTIC command, "reserved" for all other commands that I could see. Maybe the proper logic would be to switch ioctl_send_command() functions based on the version field in the INQUIRY data as you suggest, and then in the SCSI3 case, handle SEND_DIAGNOSTIC separately? I hereby retract my patch until a better solution is agreed upon that doesn't break SCSI backward compatability. Thanks, Matt -Original Message- From: Guest section DW [mailto:[EMAIL PROTECTED]] Sent: Monday, September 18, 2000 3:57 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTIC S reserved bits On Mon, Sep 18, 2000 at 11:31:09AM -0500, [EMAIL PROTECTED] wrote: 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 kernels 2.2.18-pre8 and 2.4.0-test9-pre1. -cmd[1] = ( cmd[1] 0x1f ) | (dev-lun 5); +if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND DIAGNOSTICS reserved bits + cmd[1] = (cmd[1] 0x1f) | (dev-lun 5); I am a bit surprised: why only SEND DIAGNOSTICS? If I am not mistaken SCSI-1 used this 3-bit LUN field in all commands, and SCSI-2 still does, but the standard says: 7.2.2 Logical unit number ... NOTICE: The logical unit number field is included in the command descriptor block for compatibility with some SCSI-1 devices. This field may be reclaimed in SCSI-3. and SCSI-3 calls these bits "reserved", for all commands, also for SEND DIAGNOSTICS. So: (i) I don't see what is special with SEND DIAGNOSTICS. Maybe for SCSI-3 the lun should never be inserted. (ii) On the other hand, for SCSI-1 the lun should always be inserted. Once these bits really get used again (are there already examples of a new use?) I suppose we should introduce a new SCSI3_IOCTL_SEND_COMMAND instead of changing SCSI_IOCTL_SEND_COMMAND. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTICS reserved bits
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 kernels 2.2.18-pre8 and 2.4.0-test9-pre1.
Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team
--- 2.2.18-pre8-linux/drivers/scsi/scsi_ioctl.c.origMon Sep 18 07:47:45
2000
+++ 2.2.18-pre8-linux/drivers/scsi/scsi_ioctl.c Mon Sep 18 07:48:29 2000
@@ -254,7 +254,8 @@
/*
* Set the lun field to the correct value.
*/
-cmd[1] = ( cmd[1] & 0x1f ) | (dev->lun << 5);
+if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND DIAGNOSTICS
reserved bits
+ cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5);
switch (opcode)
{
--- 2.4.0-test9-pre1-linux/drivers/scsi/scsi_ioctl.c.orig Mon Sep 18
07:37:36 2000
+++ 2.4.0-test9-pre1-linux/drivers/scsi/scsi_ioctl.cMon Sep 18 07:41:36
2000
@@ -266,7 +266,8 @@
/*
* Set the lun field to the correct value.
*/
- cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5);
+ if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND
DIAGNOSTICS reserved bits
+ cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5);
switch (opcode) {
case FORMAT_UNIT:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: PERCRAID 3 drivers?
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: Jon Mitchell Cc: [EMAIL PROTECTED] Subject: Re: PERCRAID 3 drivers? Though I am concerned about the KNOWNBUGS file that was in the 1.0.3 patch but was removed by the later version patches. It seems to indicate its a bad idea to compile it directly in the kernel. Is it better to compile it as a module? Thanks for your time... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: PERCRAID 3 drivers?
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: Jon Mitchell Cc: [EMAIL PROTECTED] Subject: Re: PERCRAID 3 drivers? Though I am concerned about the KNOWNBUGS file that was in the 1.0.3 patch but was removed by the later version patches. It seems to indicate its a bad idea to compile it directly in the kernel. Is it better to compile it as a module? Thanks for your time... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTICS reserved bits
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 kernels 2.2.18-pre8 and 2.4.0-test9-pre1.
Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team
--- 2.2.18-pre8-linux/drivers/scsi/scsi_ioctl.c.origMon Sep 18 07:47:45
2000
+++ 2.2.18-pre8-linux/drivers/scsi/scsi_ioctl.c Mon Sep 18 07:48:29 2000
@@ -254,7 +254,8 @@
/*
* Set the lun field to the correct value.
*/
-cmd[1] = ( cmd[1] 0x1f ) | (dev-lun 5);
+if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND DIAGNOSTICS
reserved bits
+ cmd[1] = (cmd[1] 0x1f) | (dev-lun 5);
switch (opcode)
{
--- 2.4.0-test9-pre1-linux/drivers/scsi/scsi_ioctl.c.orig Mon Sep 18
07:37:36 2000
+++ 2.4.0-test9-pre1-linux/drivers/scsi/scsi_ioctl.cMon Sep 18 07:41:36
2000
@@ -266,7 +266,8 @@
/*
* Set the lun field to the correct value.
*/
- cmd[1] = (cmd[1] 0x1f) | (dev-lun 5);
+ if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND
DIAGNOSTICS reserved bits
+ cmd[1] = (cmd[1] 0x1f) | (dev-lun 5);
switch (opcode) {
case FORMAT_UNIT:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: PERCRAID 3 drivers?
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 Development Team > -Original Message- > From: Bruce A. Locke [mailto:[EMAIL PROTECTED]] > Sent: Sunday, September 17, 2000 7:37 AM > To: [EMAIL PROTECTED] > Subject: PERCRAID 3 drivers? > > > > Hello... > > The organization I do some work for purchased a rackmount server from > Dell with the intent of running some webconferencing software under > Linux. The salesman we had spoken to assured us that Linux fully > supported the machine. Yeah... Right... :) > > Now it seems I'm stuck with a PERCRAID 3 card that only has > support in > the form of a binary kernel module for kernel 2.2.14 (w/ redhat's > patches). While the box runs fine with this kernel, I would definatly > like to upgrade the kernel to something that doesn't have so > many known > flaws ;) The machine is already in use so switching raid > cards isn't much > of an option at this time. > > A check of Dell's (rather horrible) support website only turns up the > binary module mentioned above. Does anyone know anything about these > PERCRAID 3 cards and if there is an opensource driver? or at least a > binary module for a newer kernel? > > Thanks for your time... > > -- > Bruce A. Locke > [EMAIL PROTECTED] > > "The Internet views censorship as damage and routes around it" > www.eff.org www.peacefire.org > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: PERCRAID 3 drivers?
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 Development Team -Original Message- From: Bruce A. Locke [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 17, 2000 7:37 AM To: [EMAIL PROTECTED] Subject: PERCRAID 3 drivers? Hello... The organization I do some work for purchased a rackmount server from Dell with the intent of running some webconferencing software under Linux. The salesman we had spoken to assured us that Linux fully supported the machine. sarcasm Yeah... Right... /sarcasm :) Now it seems I'm stuck with a PERCRAID 3 card that only has support in the form of a binary kernel module for kernel 2.2.14 (w/ redhat's patches). While the box runs fine with this kernel, I would definatly like to upgrade the kernel to something that doesn't have so many known flaws ;) The machine is already in use so switching raid cards isn't much of an option at this time. A check of Dell's (rather horrible) support website only turns up the binary module mentioned above. Does anyone know anything about these PERCRAID 3 cards and if there is an opensource driver? or at least a binary module for a newer kernel? Thanks for your time... -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
