Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
On Tue, 31 Jul 2007 23:12:26 +0300
Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> The tested Kernels:
>
> 1. Jens's sglist-arch
> I was not able to pass all tests with this Kernel. For some reason when
> bigger than 256 pages commands are queued the Machine will run out
> of memory and will kill the test. After the test is killed the system
> is left with 10M of memory and can hardly reboot.
> I have done some prints at the queuecommand entry in scsi_debug.c
> and I can see that I receive the expected large sg_count and bufflen
> but unlike other tests I get a different pointer at scsi_sglist().
> In other tests since nothing is happening at this machine while in
> the test, the sglist pointer is always the same. commands comes in,
> allocates memory, do nothing in scsi_debug, freed, and returns.
> I suspect sglist leak or allocation bug.
Ok, I found the leak.
>From 011c05c2e514d1db4834147ed83526473711b0a3 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Mon, 6 Aug 2007 16:16:24 +0900
Subject: [PATCH] fix sg chaining leak
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 5884b1b..25988b9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -48,7 +48,6 @@ static struct scsi_host_sg_pool scsi_sg_pools[] = {
SP(32),
SP(64),
SP(128),
- SP(256),
};
#undef SP
--
1.5.2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Mptlinux crashes on kernel 2.6.22.1
Here's some more info on my configuration and the output of lspci -vv (with the driver disabled, as it crashes otherwise). The kernel config contains some extra options, as it is customized. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.1 # Mon Aug 6 11:25:06 2007 # # CONFIG_PPC64 is not set CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # # CONFIG_CLASSIC32 is not set # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_85xx is not set CONFIG_PPC_86xx=y # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # # CONFIG_MODULES is not set # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Platform support # # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PQ2ADS is not set # CONFIG_MPC8641_HPCN is not set CONFIG_SBS_CM6=y CONFIG_MPC8641=y CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set # CONFIG_PPC_I8259 is not set # CONFIG_PPC_RTAS is not set # CONFIG_MMIO_NVRAM is not set # CONFIG_PPC_MPC106 is not set # CONFIG_PPC_970_NAP is not set # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_CPM2 is not set # # Kernel options # CONFIG_HIGHMEM=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_IRQ_ALL_CPUS is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_PROC_DEVICETREE=y # CONFIG_CMDLINE_BOOL is not set # CONFIG_PM is not set # CONFIG_SECCOMP is not set # CONFIG_WANT_DEVICE_TREE is not set CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PPC_INDIRECT_PCI_BE=y CONFIG_FSL_SOC=y CONFIG_FSL_PCIE=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set # # Advanced setup # CONFIG_ADVANCED_OPTIONS=y # CONFIG_HIGHMEM_START_BOOL is not set CONFIG_HIGHMEM_START=0xfe00 CON
glibc and make headers_install_all provide /usr/include/scsi
glibc and make headers_install_all provide /usr/include/scsi One of them has to go. A quick diff shows no differences, expect: scsi.h: glibc #define STATUS_MASK 0x3e Linux #define STATUS_MASK 0xfe glibc #define ABORT 0x06 Linux #define ABORT_TASK_SET 0x06 sg.h:struct sg_iovec ->sg_iovec unsigned char * in glibc void * in Linux glibc #define SG_DEFAULT_RETRIES 1 Linux #define SG_DEFAULT_RETRIES 0 Which copy should be provided by a distributor? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: glibc and make headers_install_all provide /usr/include/scsi
On Mon, Aug 06, 2007 at 02:45:46PM +0200, Olaf Hering wrote: > > glibc and make headers_install_all provide /usr/include/scsi > One of them has to go. > > A quick diff shows no differences, expect: .. > Which copy should be provided by a distributor? The glibc one of course. The kernel scsi.h should never have been added to the list of exportable headers. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] do not export /usr/include/scsi in make headers_install
On Mon, Aug 06, Christoph Hellwig wrote: > On Mon, Aug 06, 2007 at 02:45:46PM +0200, Olaf Hering wrote: > > > > glibc and make headers_install_all provide /usr/include/scsi > > One of them has to go. > > > > A quick diff shows no differences, expect: > > .. > > > Which copy should be provided by a distributor? > > The glibc one of course. The kernel scsi.h should never have been > added to the list of exportable headers. /usr/include/scsi is provided by glibc. Remove the scsi export from make headers_install target. Signed-off-by: Olaf Hering <[EMAIL PROTECTED]> --- include/Kbuild |1 - include/scsi/Kbuild |4 2 files changed, 5 deletions(-) --- a/include/Kbuild +++ b/include/Kbuild @@ -1,6 +1,5 @@ header-y += asm-generic/ header-y += linux/ -header-y += scsi/ header-y += sound/ header-y += mtd/ header-y += rdma/ --- a/include/scsi/Kbuild +++ /dev/null @@ -1,4 +0,0 @@ -header-y += scsi.h - -unifdef-y += scsi_ioctl.h -unifdef-y += sg.h - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ps3rom: convert to use the data buffer accessors
On Mon, 23 Jul 2007, FUJITA Tomonori wrote: > This is against Linus' tree since scsi-misc doesn't include ps3rom > driver yet. > > --- > From: FUJITA Tomonori <[EMAIL PROTECTED]> > Subject: [PATCH] ps3rom: convert to use the data buffer accessors > > This converts ps3rom driver to use the new accessors for the sg lists > and the parameters. > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> Acked-by: Geert Uytterhoeven <[EMAIL PROTECTED]> With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [Cbe-oss-dev] Playstation 3 BD-ROM access and LV1_DENIED_BY_POLICY
On Fri, 3 Aug 2007, Geoff Levand wrote: > Nicholas A. Bellinger wrote: > > Thank you for this information. I since been able to resolve my issue > > on 2.6.16 (which ended up being my fault), and was able to determine > > that the issue on 2.6.23-rc1 is due to > > drivers/scsi/scsi_lib.c:scsi_execute_async() rejecting READ_10 and > > TEST_UNIT_READY commands in certain cases (perhaps a race in > > drivers/scsi/ps3rom.c..?) using this API that was causing the win32 side > > to throw exceptions. > > If you get more info on what was happening here, please report it to Geert > so he can investigate. He should return next week. Indeed. Perhaps because ps3rom cannot queue more than 1 command? I'm CCing the SCSI guys, just in case this rings a bell. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [Cbe-oss-dev] Playstation 3 BD-ROM access and LV1_DENIED_BY_POLICY
On Mon, 2007-08-06 at 15:38 +0200, Geert Uytterhoeven wrote: > On Fri, 3 Aug 2007, Geoff Levand wrote: > > Nicholas A. Bellinger wrote: > > > Thank you for this information. I since been able to resolve my issue > > > on 2.6.16 (which ended up being my fault), and was able to determine > > > that the issue on 2.6.23-rc1 is due to > > > drivers/scsi/scsi_lib.c:scsi_execute_async() rejecting READ_10 and > > > TEST_UNIT_READY commands in certain cases (perhaps a race in > > > drivers/scsi/ps3rom.c..?) using this API that was causing the win32 side > > > to throw exceptions. > > > > If you get more info on what was happening here, please report it to Geert > > so he can investigate. He should return next week. > > Indeed. > > Perhaps because ps3rom cannot queue more than 1 command? > I'm CCing the SCSI guys, just in case this rings a bell. Without details, it's really hard to speculate. The problem description is manifestly strange for two reasons 1. READ_10 should never be issued via scsi_execute_async. There's no ULD in the current kernel that does this. The READ_X/WRITE_X commands are issued through the filesystem path. 2. There's no command filter in there either: I can imagine an eh problem where the LLD isn't accepting the TUR because it still thinks the just recovered command is outstanding. So could we have some actual details? James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Cbe-oss-dev] Playstation 3 BD-ROM access and LV1_DENIED_BY_POLICY
On Mon, 6 Aug 2007, James Bottomley wrote: > On Mon, 2007-08-06 at 15:38 +0200, Geert Uytterhoeven wrote: > > On Fri, 3 Aug 2007, Geoff Levand wrote: > > > Nicholas A. Bellinger wrote: > > > > Thank you for this information. I since been able to resolve my issue > > > > on 2.6.16 (which ended up being my fault), and was able to determine > > > > that the issue on 2.6.23-rc1 is due to > > > > drivers/scsi/scsi_lib.c:scsi_execute_async() rejecting READ_10 and > > > > TEST_UNIT_READY commands in certain cases (perhaps a race in > > > > drivers/scsi/ps3rom.c..?) using this API that was causing the win32 side > > > > to throw exceptions. > > > > > > If you get more info on what was happening here, please report it to Geert > > > so he can investigate. He should return next week. > > > > Indeed. > > > > Perhaps because ps3rom cannot queue more than 1 command? > > I'm CCing the SCSI guys, just in case this rings a bell. > > Without details, it's really hard to speculate. The problem description > is manifestly strange for two reasons > > 1. READ_10 should never be issued via scsi_execute_async. There's > no ULD in the current kernel that does this. The READ_X/WRITE_X > commands are issued through the filesystem path. > 2. There's no command filter in there either: I can imagine an eh > problem where the LLD isn't accepting the TUR because it still > thinks the just recovered command is outstanding. > > So could we have some actual details? Nicholas is using the PS3 as an iSCSI target for watching BD-ROM content on other machines. That's probably where the weird command submission comes from. He will hopefully fill in the rest... With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: Some quick scsi documentation questions:
On Sunday 05 August 2007 11:50:33 am Douglas Gilbert wrote:
> Stefan Richter wrote:
> > Rob Landley wrote:
> >> So an sg device is for something like a scanner that doesn't
> >> present a block device?
> >
> > That's what I heard.
>
> The sg driver is a SCSI pass-through while the bsg driver is
> a pass-through the specializes in SCSI and other (usually)
> storage related protocols. Both work at the level of industry
> recognized standard (and draft) protocols.
>
> That approach makes the Linux block layer either a nuisance,
> irrelevant or a complete anachronism (in the case of OSD).
There are non-scsi block devices in the world, you know.
> IMO the linux block layer should be morphed into a library
> of internal queue handling routines. Storage upper level
> drivers such as sd can continue to present the "block"
> view ** of storage devices such as disks.
Ok, so when do embedded flash volumes (non-USB) start getting routed through
the scsi layer? Shortly after ramdisks do?
> ** In OO terminology a storage device may have a "block"
>interface. A storage device is not derived from "block".
I have no idea what that means.
> In practical terms the block layer SG_IO ioctl is still a
> scaled down version of what the corresponding ioctl in
> the sg driver can do.
Is there anything interesting that you _can't_ do through SG_IO that you could
do through sg?
> The block layer SG_IO ioctl is saddled
> with whatever strange policy the upper level driver might
> have for that device class (e.g. wait forever if removal media
> is not present). Also the block layer SG_IO ioctl cannot do
> asynchronous IO (either can the bsg driver at the moment).
This sounds like A) an implementation detail, B) a performance hack for
seldom-used things like low level formats.
> There was a version of Fedora that came out with sg devices
> only available for SCSI devices not already claimed by
> other upper level drivers. It was a surprise to me (Arjan
> may have mentioned it on this list). I got some complaints
> (as if I could do anything). Anyway it was amusing
> to watch how quickly that misstep was reversed. Obviously
> some folks with a lot me influence than me got to the Fedora
> designers who did that.
Fedora is the new name for Red Hat Enterprise Rawhide. Red Hat figured out
how Sun made all its money (large corporate and government purchasing
contracts that cap the profit at the percentage of the cost of materials, so
people bidding on those contracts spec the most expensive materials they can.
If they use a $25 copy of Linux they get $2.50 but if they use a $5000 copy
of Solaris they get $500. And so they went "hey, if it makes you happy we
can charge $5000 too" and came out with Red Hat Enterprise, which was so
lucrative they left everything else behind.)
These days Fedora listens to money, not to technology. If somebody like IBM
says "do X, here's a big check", are they going to turn it down?
> >> There are such things as external SATA enclosures, but
> >> they're A) few and far between,
> >
> > What? They are all the rage now. :-)
>
> ATA8-ACS (still draft I think) has provision for a NAA-5
> based UUID. Not sure if any SATA disks are complying
> yet. [I don't think the Seagate ES series ("enterprise")
> did so it will be interesting if their recently announced
> ES.2 series does.]
>
> Yes SATA external enclosures are everywhere. They make more
> sense than USB 2 and marginalize 1394. The problems start
> for SATA when you want to have more than one disk in that
> enclosure. SAS is much better as an interconnect.
My point is that there are something like ten million of laptops produced
annually and with enclosures you're talking about a technology where the
entire production run generally doesn't hit six figures in unit volume. That
would be "few and far between" in my book. (Don't get me started on cell
phones. :)
> >> In 99.x% of systems with SATA hard drives, said drives are sealed inside
> >> the machine, whether it's a laptop or a server. USB can move around
> >> between boots (or with the power on) as a matter of course, but SATA
> >> really isn't designed for that or expected to do that.
> >
> > I suppose you could still have a not too complicated topology-based
> > naming scheme even with eSATA.
>
> Recent SAS-2 drafts have some heuristic for ATA disks (that
> don't have real UUIDs) that combines the manufacturer, model
> and serial number into a single number for identification
> purposes. With potentially hundreds of SATA disks hanging
> off SAS infrastructure, someone who changed the slot a SATA
> disk was connected to could cause a lot of fun.
But there aren't potentially hundreds of SATA disks hanging off my laptop, and
my laptop is actually a common case of hardware. You are penalizing the
common case in favor of systems that cost more than the salary of the
full-time professional system administrator assigned to them.
> >> You can reliably enumerate ATA an
Re: Some quick scsi documentation questions:
Rob Landley wrote: > On Sunday 05 August 2007 11:50:33 am Douglas Gilbert wrote: >> Stefan Richter wrote: >>> Rob Landley wrote: There are such things as external SATA enclosures, but they're A) few and far between, >>> What? They are all the rage now. :-) ... > My point is that there are something like ten million of laptops produced > annually and with enclosures you're talking about a technology where the > entire production run generally doesn't hit six figures in unit volume. That > would be "few and far between" in my book. (Don't get me started on cell > phones. :) The case of a laptop with a single sealed "spindle" (and maybe an optical drive) is easy. Among else, you have the following options: - Let the distributor figure it out for you. - Link the driver for the onboard SATA controller statically into the kernel. Make all other SCSI low-level providers (e.g. usb- storage) modular. In other words, if SATA and USB and other disks are mixed up, let the distributor deal with the mix-up. You only ever deal with device aliases in /dev/disk/by-*/ or with an even higher-level representation by the desktop environment. _Or_ you enforce that the built-in SATA drive is always /dev/sda, by having this drive always added first. ... > Right now "this is a SATA drive" isn't exposed in sysfs, that I can find. Have a look at the udev scripts or at Doug's lsscsi. Or simply use lsscsi like a blackbox. -- Stefan Richter -=-=-=== =--- --==- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [2/2] 2.6.23-rc2: known regressions with patches
> > Caused-By : Thomas Renninger <[EMAIL PROTECTED]> > > commit 29b71a1ca74491fab9fed09e9d835d840d042690 > A patch was sent to Tony. AFAIK it got accepted, not sure whether it > already is in any and which git tree... The suggested patch adds manual padding to the acpi_device_id structure definition in include/linux/mod_devicetable.h I didn't take it, and it appears that nobody else did either. It is not in Linus' tree (as of 2.6.23-rc2). I expressed doubts about whether this is the right fix. The problem is that when cross-compiling a locally compiled utility makes a size & alignment check. This is bogus. We shouldn't care whether this structure compiles to the same size/alignment as the kernel that will use on the target platform. Is fixing this the right way (make the scripts/mod/file2alias.c understand target alignment rules in a cross environment) just too hideous to contemplate ... and we should just sacrifice 7 bytes of padding in order to keep life simple? -Tony - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
An MCA ESP driver
This is about 90% complete. I need to implement:
drivers/scsi/mca_53c9x.c:191: error: 'mca_esp_reset_dma' undeclared here (not
in a function)
drivers/scsi/mca_53c9x.c:192: error: 'mca_esp_dma_drain' undeclared here (not
in a function)
drivers/scsi/mca_53c9x.c:193: error: 'mca_esp_dma_invalidate' undeclared here
(not in a function)
drivers/scsi/mca_53c9x.c:195: error: 'mca_esp_dma_error' undeclared here (not
in a function)
I thought I'd post what I have so far. If you compare it to the
mca_53c9x driver currently in-tree, you'll see that davem's new core is
much nicer. I had to make one tiny change to the esp driver core:
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index 856e38b..fc8437d 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -514,11 +514,14 @@ struct esp {
struct completion *eh_reset;
- struct sbus_dma *dma;
+ union {
+ struct sbus_dma *sbus_dma;
+ unsigned intx86_dma;
+ };
};
/* A front-end driver for the ESP chip should do the following in
- * it's device probe routine:
+ * its device probe routine:
* 1) Allocate the host and private area using scsi_host_alloc()
*with size 'sizeof(struct esp)'. The first argument to
*scsi_host_alloc() should be &scsi_esp_template.
(er, I suppose I need to touch up the sun_esp driver to match the name
change).
Anyway, the new driver:
/* mca_53c9x.c: Driver for the SCSI adapter found on NCR 35xx
* (and maybe some other) Microchannel machines
*
* Code taken mostly from Cyberstorm SCSI drivers
* Copyright (C) 1996 Jesper Skov ([EMAIL PROTECTED])
*
* Hacked to work with the NCR MCA stuff by Tymm Twillman ([EMAIL PROTECTED])
*
* The CyberStorm SCSI driver (and this driver) is based on David S. Miller's
* ESP driver * for the Sparc computers.
*
* Special thanks to Ken Stewart at Symbios (LSI) for helping with info on
* the 86C01. I was on the brink of going ga-ga...
*
* Also thanks to Jesper Skov for helping me with info on how the Amiga
* does things...
*/
/*
* Info on the 86C01 MCA interface chip at the bottom, if you care enough to
* look.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "scsi.h"
#include "esp_scsi.h"
/* Tell the 86C01 to stop sending interrupts */
static void mca_esp_disable_irq(struct esp *esp)
{
u8 mode_enable = ioread8(esp->dma_regs + 2);
iowrite8(mode_enable & ~0x40, esp->dma_regs + 2);
}
/* Tell the 86C01 to give us interrupts */
static void mca_esp_enable_irq(struct esp *esp)
{
u8 mode_enable = ioread8(esp->dma_regs + 2);
iowrite8(mode_enable | 0x40, esp->dma_regs + 2);
}
/*
* We keep the structure that is used to access the registers on the 53c9x
* here.
*/
static struct ESP_regs eregs;
/* DMA Functions */
static int dma_bytes_sent(struct esp *esp, int fifo_count)
{
/* Ask the 53c9x. It knows. */
return fifo_count;
}
static int dma_can_transfer(struct esp *esp, Scsi_Cmnd *sp)
{
/*
* The MCA dma channels can only do up to 128K bytes at a time.
* (16 bit mode)
*/
unsigned long sz = sp->SCp.this_residual;
if(sz > 0x2)
sz = 0x2;
return sz;
}
#if 0
static void dma_dump_state(struct esp *esp)
{
/*
* Doesn't quite match up to the other drivers, but we do what we
* can.
*/
ESPLOG(("esp%d: dma channel <%d>\n", esp->esp_id, esp->x86_dma));
ESPLOG(("bytes left to dma: %d\n", mca_get_dma_residue(esp->x86_dma)));
}
/*
* These will not play nicely with other disk controllers that try to use the
* disk active LED... but what can you do? Don't answer that.
*
* Stolen shamelessly from ibmmca.c -- IBM Microchannel SCSI adapter driver
*/
#define PS2_SYS_CTR 0x92
static void dma_led_on(struct esp *esp)
{
outb(inb(PS2_SYS_CTR) | 0xc0, PS2_SYS_CTR);
}
static void dma_led_off(struct esp *esp)
{
outb(inb(PS2_SYS_CTR) & 0x3f, PS2_SYS_CTR);
}
/*
* Check to see if interrupts are enabled on the 'C01 (in case abort
* is entered multiple times, so we only do the abort once)
*/
static int dma_ports_p(struct esp *esp)
{
return (ioread8(esp->dma_regs + 2) & 0x40) ? 1 : 0;
}
#endif
static void mca_esp_write8(struct esp *esp, u8 val, unsigned long reg)
{
iowrite8(val, esp->regs + reg);
}
static u8 mca_esp_read8(struct esp *esp, unsigned long reg)
{
return ioread8(esp->regs + reg);
}
static dma_addr_t mca_esp_map_single(struct esp *esp, void *buf, size_t sz,
int dir)
{
return dma_map_single(esp->dev, buf, sz, dir);
}
static int mca_esp_map_sg(struct esp *esp, struct scatterlist *sg, int num_sg,
int dir)
{
Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2
On Sat, 4 Aug 2007, James Bottomley wrote: > > This is mainly bug fixes ... there's one or two features completions > that have been delayed pending ack and review to do with bsg (headers > and passthrough) but these are really required to complete already > upstream code. James, this is the last time *ever* I apply patches from you after -rc1. You used to have serious problems with the merge window, but for a few releases you then seemed to "get it" and got on with the program. But now it's back to "anythign goes", apparently. And I'm going to take a hard-line approach with you now. For SCSI merges, if I don't get the first pull request in the FIRST week of the merge window, don't bother sending one later, unless it's pure fixes and regressions. And after -rc1, I don't want to see crap like this: 46 files changed, 2837 insertions(+), 2050 deletions(-) because that simply is *not* appropriate after -rc1, much less -rc2. So I pulled, but I wanted to make it very clear that I'm very unhappy with you right now, and you're on my shit-list for the next few releases. Get the changes in before -rc1, or just *wait*. If they aren't ready before the merge window opens, they simply shouldn't be merged at all. Linus - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2
On Mon, 2007-08-06 at 17:51 -0700, Linus Torvalds wrote: > > On Sat, 4 Aug 2007, James Bottomley wrote: > > > > This is mainly bug fixes ... there's one or two features completions > > that have been delayed pending ack and review to do with bsg (headers > > and passthrough) but these are really required to complete already > > upstream code. > > James, this is the last time *ever* I apply patches from you after -rc1. > > You used to have serious problems with the merge window, but for a few > releases you then seemed to "get it" and got on with the program. > > But now it's back to "anythign goes", apparently. And I'm going to take a > hard-line approach with you now. > > For SCSI merges, if I don't get the first pull request in the FIRST week > of the merge window, don't bother sending one later, unless it's pure > fixes and regressions. Confused ... you did get the first pull request in the first week. That was this: Subject: [GIT PATCH] first SCSI merge for 2.6.22 Date: Sun, 15 Jul 2007 10:24:17 -0500 190 files changed, 21725 insertions(+), 26337 deletions(-) Then there was the last piece before the merge window closed: Subject: [GIT PATCH] final piece of the SCSI merge for 2.6.22 Date: Sun, 22 Jul 2007 13:28:53 -0500 74 files changed, 3649 insertions(+), 1295 deletions(-) > And after -rc1, I don't want to see crap like this: > >46 files changed, 2837 insertions(+), 2050 deletions(-) > > because that simply is *not* appropriate after -rc1, much less -rc2. > > So I pulled, but I wanted to make it very clear that I'm very unhappy with > you right now, and you're on my shit-list for the next few releases. Get > the changes in before -rc1, or just *wait*. If they aren't ready before > the merge window opens, they simply shouldn't be merged at all. OK ... that's arguable. This one is larger than I like because of the lpfc bug fix patch ... I accept I need to do a better job getting these into the merge window via the scsi-misc tree. So I will accept the "too big" criticism and try to manage the driver maintainers better. However, I won't accept the "not bug fixes only" criticism at -rc1. The problem is that we're trying to stabilise a new feature: bsg. Unfortunately, the closure of the merge window was really the first time anyone got to play with all of these features together. The non-bug fix changes around bsg have been trying to achieve stability. The problem is that there were a few fairly problematic pieces: dependence on non-modular SCSI; SG header layout and driver implementation. What we really don't want is to have a problematic API baked in stone because we can't do anything other than bug fix updates once the merge window closes. The real root cause of all of this is that there's no tree I can persuade all the interested parties to test that includes all of these features. In spite of the fact they've all been incubating in -mm for at least 3 months, no-one apparently tested all the features together until 2.6.23-rc1 was released, so then we're scrambling to address the issues as they arise. I really, *really* think we need a pre-release tree that consists of all the upstream targetted features (i.e. all of the for the next merge window git trees) and nothing else. -mm doesn't really satisfy this, because it has so much other stuff that the people I need to get testing this don't trust it. The lack of a tree like this that we could have persuaded people to test for the last month is what's causing us to scramble like this at the closure of the merge window. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2
On Mon, 6 Aug 2007, James Bottomley wrote: > > Confused ... you did get the first pull request in the first week. Here's the problem. Let me repeat it again: > > And after -rc1, I don't want to see crap like this: > > > > 46 files changed, 2837 insertions(+), 2050 deletions(-) It DOES NOT MATTER if I get a first pull request in the first week, if that pull request is purely cosmetic, and is followed by stuff that *should* have been in the merge window four weeks afterwards. > OK ... that's arguable. There's nothing arguable at all about it. If you have 5000 lines of changes, that's not a "bugfix" any more. That's a big damn change, and it should have happened in the merge window. Or if it doesn't make it in time, in the *next* merge window. Linus - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
