headers
Sid Boyce | 1 Apr 2004 01:05
Picon
Favicon

Re: 2.6.5-rc3-mm1

Andi Kleen wrote:

>Sid Boyce <sboyce <at> blueyonder.co.uk> writes:
>  
>
>>2.6.5-rc2 booting OK(with acpi), anything else 2.6.5-rc2-mm?,
>>2.6.5-rc3 or2.6.5-rc3-mm1 freezes.
>>    
>>
>
>Could you perhaps build your kernel with netconsole and builtin
>network driver (see Documentation/networking/netconsole.txt) and get
>a full boot log?  You can send it to me privately.
>
>-Andi
>
>
>
>  
>
The laptop does not have a serial console and it does not get as far as 
networking during boot.
Regards
Sid.

--

-- 
Sid Boyce .... Hamradio G3VBV and keen Flyer
Linux Only Shop.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Boutcher | 1 Apr 2004 01:12
Picon
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

On Wed, 31 Mar 2004 17:02:02 -0500, Jeff Garzik <jgarzik <at> pobox.com> wrote:
> Comments:
>
> 1) Would be nice to eliminate  module options for commands-per-lun, 
> max-requests etc. and actually have the driver figure out the real 
> needs.  One or two options could fall into the "performance tuning" 
> category, and stay, but the others are really dependent on the 
> underlying configuration and underlying limits.
Hmmm...well, I could collapse the two together, since commands_per_lun
is not limited by anything specific for this adapter.  I would prefer
to leave them broken out to handle users who have extreme requirements.

> 2) why is one-descriptor a special case in map_sg_data()?  You proceed 
> to do the same thing in a loop, right below that...  AFAICS you can just 
> use the loop, and clamp the number of scatterlist elements to one.
The SRP spec has two different buffer formats: SRP_DIRECT_BUFFER for a
single buffer, and SRP_INDIRECT_BUFFER for lists of buffers, and the
layout of the buffers in the request is different for those two cases.

> 3) in the following code...
>
> +	if ((evt_struct->crq.format == VIOSRP_SRP_FORMAT) &&
> +	    (atomic_dec_if_positive(&hostdata->request_limit) < 0)) {
> +		printk("ibmvscsi: Warning, request_limit exceeded\n");
> +		unmap_cmd_data(&evt_struct->evt->srp.cmd, hostdata->dev);
> +		ibmvscsi_free_event_struct(&hostdata->pool, evt_struct);
> +		return SCSI_MLQUEUE_HOST_BUSY;
> +	}
>
> is the code prepared to deal with hostdata->request_limit being negative?
(Continue reading)

Permalink | Reply | 12 comments |
headers
Jesse Barnes | 1 Apr 2004 01:15
Picon
Favicon

Re: 2.6.5-rc1-mm2

On Wednesday 31 March 2004 12:06 pm, Andrew Morton wrote:
> So are we to assume that this is the offending process?  That the periodic
> slab reaping code has screwed up?

It looks like it.  Disabling the slab cache reaping function allows it to boot 
again.

Jesse
Permalink | Reply | 4 comments |
headers
Stephen C. Tweedie | 1 Apr 2004 01:20
Picon
Favicon

Re: msync() behaviour broken for MS_ASYNC, revert patch?

Hi,

On Wed, 2004-03-31 at 23:53, Andrew Morton wrote:
> "Stephen C. Tweedie" <sct <at> redhat.com> wrote:

> > Unfortunately, this seems to contradict SingleUnix requirements, which
> > state:
> >         When MS_ASYNC is specified, msync() shall return immediately
> >         once all the write operations are initiated or queued for
> >         servicing
> > although I can't find an unambiguous definition of "queued for service"
> > in the online standard.  I'm reading it as requiring that the I/O has
> > reached the block device layer

> I don't think I agree with that.  If "queued for service" means we've
> started the I/O, then what does "initiated" mean, and why did they specify
> "initiated" separately?

I'd interpret "initiated" as having reached hardware.  "Queued for
service" is much more open to interpretation: Uli came up with "the data
must be actively put in a stage where I/O is initiated", which still
doesn't really address what sort of queueing is allowed.

> What triggered all this was a dinky little test app which Linus wrote to
> time some aspect of P4 tlb writeback latency.  It sits in a loop dirtying a
> page then msyncing it with MS_ASYNC.  It ran very poorly, because MS_ASYNC
> ended up waiting on the previously-submitted I/O before starting new I/O.

Sure.  There are lots of ways an interface can be misused, though: you
only know if one use is valid or not once you've determined what the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 Apr 2004 01:22
Gravatar

Re: [Fwd: Re: PATCH -- kobject_set_name() doesn't allocate enough space]

On Fri, Mar 26, 2004 at 09:17:22PM -0600, Linda Xie wrote:
> Greg KH wrote:
> 
> >On Fri, Mar 26, 2004 at 03:07:34PM -0600, Linda Xie wrote:
> > 
> >
> >>Hi Linus,
> >>
> >>
> >>Please see attached patch at the end of FW mail and apply it to your tree.
> >>   
> >>
> >
> >Your patch is munged again and will not apply :(
> >
> >Can you send me a new version?  I'll apply it to my tree and let it get
> >tested in the -mm tree before sending it on to Linus.

> Sounds good.  See below for the patch. If it doesn't work, try the 
> attachement.

The attachment worked, I've applied it to my trees and will forward it
on.

thanks,

greg k-h
Permalink | Reply | 0 comments |
headers
James Bottomley | 1 Apr 2004 01:39
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

On Wed, 2004-03-31 at 18:12, Dave Boutcher wrote:
> OK, two issues.  There are a bunch of SCSI LLDDs that use this same
> logic in abort and reset handlers to wait for adapter events to
> complete, so I think the logic is OK.  The issue of spin_lock_irq
> vs spin_lock is a good one...and points out that there are a bunch
> of LLDDs that are broke :-)  I'll resubmit without the _irq

Actually, no, with the irq is correct.  Wait_for_completion will sleep,
and sleeping with interrupts disabled is wrong.

The reason for this is that the error handler takes the host lock around
calls to the driver error handler functions.  The rationale was that
"simple" drivers didn't want to bother with locking, but it's obviously
causing more problems than it solves.

> > 14) why are you faking a PCI bus?  The following is very, very wrong:
> >
> > +static struct pci_dev iseries_vscsi_dev = {
> > +	.dev.bus = &pci_bus_type,
> > +	.dev.bus_id = "vscsi",
> > +	.dev.release = noop_release
> >
> > Did I mention "very" wrong?  :)
> Because for iseries it is implemented in the pci code.  While it may
> look wrong, it is actually correct.  Check out
> arch/ppc64/kernel/iSeries_iommu.c and arch/ppc64/kernel/dma.c.
> This device has to have dev->bus == &pci_bus_type otherwise the
> dma_mapping_foo functions won't work correctly.

Erm, something is very wrong in the iSeries code then.  This
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stephen C. Tweedie | 1 Apr 2004 01:41
Picon
Favicon

Re: msync() behaviour broken for MS_ASYNC, revert patch?

Hi,

On Wed, 2004-03-31 at 23:37, Linus Torvalds wrote:
> On Wed, 31 Mar 2004, Stephen C. Tweedie wrote:
> >         
> > although I can't find an unambiguous definition of "queued for service"
> > in the online standard.  I'm reading it as requiring that the I/O has
> > reached the block device layer, not simply that it has been marked dirty
> > for some future writeback pass to catch; Uli agrees with that
> > interpretation.
> 
> That interpretation makes pretty much zero sense.
> 
> If you care about the data hitting the disk, you have to use fsync() or 
> similar _anyway_, and pretending anything else is just bogus.

You can make the same argument for either implementation of MS_ASYNC. 
And there's at least one way in which the "submit IO now" version can be
used meaningfully --- if you've got several specific areas of data in
one or more mappings that need flushed to disk, you'd be able to
initiate IO with multiple MS_ASYNC calls and then wait for completion
with either MS_SYNC or fsync().  That gives you an interface that
corresponds somewhat with the region-based filemap_sync();
filemap_fdatawrite(); filemap_datawait() that the kernel itself uses.  

> Having the requirement that it is on some sw-only request queue is
> nonsensical, since such a queue is totally invisible from a user
> perspective.

It's very much visible, just from a performance perspective, if you want
(Continue reading)

Permalink | Reply | 18 comments |
headers
Albert Cahalan | 1 Apr 2004 01:46

Re: finding out the value of HZ from userspace

> | >>>>there is one. Nothing uses it
> | >>>>(sysconf() provides this info)
> | >>>
> | >>>If you have a recent glibc on a recent kernel, it might.
> | >>>You could also get a -1 or a supposed ABI value that
> | >>>has nothing to do with the kernel currently running.
> | >>>The most reliable way is to first look around on the
> | >>>stack in search of ELF notes, and then fall back to
> | >>>some horribly gross hacks as needed.
> | >>
> | >>eh sysconf() is the nice way to get to the ELF notes
> | >>instead of having to grovel yourself.
> | > 
> | > 
> | > Unless there is some hidden feature that lets
> | > me specify the ELF note number directly, no way.
> | > 
> | > The sysconf(_SC_CLK_TCK) call does not return an
> | > error code when used on a 2.2.xx i386 kernel.
> | > You get an arbitrary value that fails for ARM,
> | > Alpha, and any system with modified HZ.
> | 
> | As Linux is supposed to be POSIX compliant this is a bug and should be 
> | fixed.
> 
> 
> My understanding (from a few years back) is that Linux is POSIX
> if/when/where it makes sense, but not necessarily POSIX-just-to-be-POSIX.

The fixing has been done.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Dave Boutcher | 1 Apr 2004 01:51
Picon
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

On 31 Mar 2004 18:39:57 -0500, James Bottomley 
<James.Bottomley <at> SteelEye.com> wrote:
>> > 14) why are you faking a PCI bus?  The following is very, very wrong:
>> >
>> > +static struct pci_dev iseries_vscsi_dev = {
>> > +	.dev.bus = &pci_bus_type,
>> > +	.dev.bus_id = "vscsi",
>> > +	.dev.release = noop_release
>> >
>> > Did I mention "very" wrong?  :)
>> Because for iseries it is implemented in the pci code.  While it may
>> look wrong, it is actually correct.  Check out
>> arch/ppc64/kernel/iSeries_iommu.c and arch/ppc64/kernel/dma.c.
>> This device has to have dev->bus == &pci_bus_type otherwise the
>> dma_mapping_foo functions won't work correctly.
>
> Erm, something is very wrong in the iSeries code then.  This
> iseries_vio_device is a struct device.  As such, it should contain all
> the information it needs for the DMA API to act on it without performing
> silly pci device tricks.
>
> This looks like it's done because the iseries should be converted to the
> generic device infrastructure, but in fact it's not.  Since the generic
> API has been around for over a year and was designed to solve precisely
> these very problems it needs fixing rather than trying to work around it
> in a driver.
There will always be 1 (no more, no less) of these struct devices in the
system, so I'll move the definition of this into iSeries_iommu and then
just reference it from the driver.  I think that should abstract things
sufficiently.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Morton | 1 Apr 2004 01:56

Re: 2.6.5-rc1-mm2

Jesse Barnes <jbarnes <at> sgi.com> wrote:
>
> On Wednesday 31 March 2004 12:06 pm, Andrew Morton wrote:
> > So are we to assume that this is the offending process?  That the periodic
> > slab reaping code has screwed up?
> 
> It looks like it.  Disabling the slab cache reaping function allows it to boot 
> again.

I suspect that the reap timer is innocent and what we have is simply
scribbled-on slab metadata.  Which means it could be anything at all.

One last thing: could you please stick a

	printk(KERN_EMERG "destroying slab %s\n", cachep->name);

at the start of slab_destroy()?  That'll help narrow it down.

Could you also punt me over the .config?  If I can make it happen, the
binary search will find it.  But it probably won't happen here.
Permalink | Reply | 3 comments |

Gmane