Will Linux ever add support for new Intel storage controllers in RAID mode?

[David F.]

Hi,

It's been quite a while now and haven't seen anything about Linux
adding support for these new Intel controllers in RAID mode.   Nothing
shows at all unless the controller is changed to AHCI mode.   The
manufactures are typically selling their systems with that controller
in RAID mode having NVMe m.2 devices with Windows.  So Linux can't be
used at all without changing things either temporarily for emergency
boot disks or altering windows as well to get Linux installed.

Someone said Intel provided a patch or firmware at some point, but
it's missing and nobody is talking about it?

Anyone?

TIA!!

Re: What populates /proc/partitions ?

[David F.]

It has something to do with devtmpfs that causes it.   If I could set
this GENHD_FL_HIDDEN flag on it, it would solve the problem on those
system that say the have a floppy but doesn't really exist.Is
something built-in to allow that or it's up to the driver itself?

On Mon, Sep 30, 2019 at 8:38 PM David F.  wrote:
>
> Well, it's not straightforward.  No direct calls, it must be somehow
> when kmod is used to load the module.  The only difference I see in
> the udevadm output is the old system has attribute differences
> capability new==11, old==1, event_poll_msec new=2000, old=-1.  I
> figured if i could set the "hidden" attribute to 1 then it looks like
> /proc/partitions won't list it (already "removable"attribute), but
> udev doesn't seem to allow changing the attributes, only referencing
> them. unless I'm missing something?
>
> On Mon, Sep 30, 2019 at 5:13 PM David F.  wrote:
> >
> > Thanks for the replies.   I'll see if I can figure this out.   I know
> > with the same kernel and older udev version in use that it didn't add
> > it, but with the new udev (eudev) it does (one big difference is the
> > new one requires and uses devtmpfs and the old one didn't).
> >
> > I tried making the floppy a module but it still loads on vmware player
> > and the physical test system I'm using that doesn't have one but
> > reports it as existing (vmware doesn't hang, just adds fd0 read errors
> > to log, but physical system does hang while fdisk -l, mdadm --scan
> > runs, etc..).
> >
> > As far as the log, debugging udev output, it's close to the same, the
> > message log (busybox) not much in there to say what's up.   I even
> > tried the old .rules that were being used with the old udev version,
> > but made no difference.
> >
> > On Mon, Sep 30, 2019 at 4:49 PM Randy Dunlap  wrote:
> > >
> > > On 9/30/19 3:47 PM, David F. wrote:
> > > > Hi,
> > > >
> > > > I want to find out why fd0 is being added to /proc/partitions and stop
> > > > that for my build.  I've searched "/proc/partitions" and "partitions",
> > > > not finding anything that matters.
> > >
> > > /proc/partitions is produced on demand by causing a read of it.
> > > That is done by these functions (pointers) in block/genhd.c:
> > >
> > > static const struct seq_operations partitions_op = {
> > > .start  = show_partition_start,
> > > .next   = disk_seqf_next,
> > > .stop   = disk_seqf_stop,
> > > .show   = show_partition
> > > };
> > >
> > > in particular, show_partition().  In turn, that function uses data that 
> > > was
> > > produced upon block device discovery, also in block/genhd.c.
> > > See functions disk_get_part(), disk_part_iter_init(), 
> > > disk_part_iter_next(),
> > > disk_part_iter_exit(), __device_add_disk(), and get_gendisk().
> > >
> > > > If udev is doing it, what function is it call so I can search on that?
> > >
> > > I don't know about that.  I guess in the kernel it is about "uevents".
> > > E.g., in block/genhd.c, there are some calls to kobject_uevent() or 
> > > variants
> > > of it.
> > >
> > > > TIA!!
> > >
> > > There should be something in your boot log about "fd" or "fd0" or floppy.
> > > eh?
> > >
> > > --
> > > ~Randy

Re: What populates /proc/partitions ?

[David F.]

Well, it's not straightforward.  No direct calls, it must be somehow
when kmod is used to load the module.  The only difference I see in
the udevadm output is the old system has attribute differences
capability new==11, old==1, event_poll_msec new=2000, old=-1.  I
figured if i could set the "hidden" attribute to 1 then it looks like
/proc/partitions won't list it (already "removable"attribute), but
udev doesn't seem to allow changing the attributes, only referencing
them. unless I'm missing something?

On Mon, Sep 30, 2019 at 5:13 PM David F.  wrote:
>
> Thanks for the replies.   I'll see if I can figure this out.   I know
> with the same kernel and older udev version in use that it didn't add
> it, but with the new udev (eudev) it does (one big difference is the
> new one requires and uses devtmpfs and the old one didn't).
>
> I tried making the floppy a module but it still loads on vmware player
> and the physical test system I'm using that doesn't have one but
> reports it as existing (vmware doesn't hang, just adds fd0 read errors
> to log, but physical system does hang while fdisk -l, mdadm --scan
> runs, etc..).
>
> As far as the log, debugging udev output, it's close to the same, the
> message log (busybox) not much in there to say what's up.   I even
> tried the old .rules that were being used with the old udev version,
> but made no difference.
>
> On Mon, Sep 30, 2019 at 4:49 PM Randy Dunlap  wrote:
> >
> > On 9/30/19 3:47 PM, David F. wrote:
> > > Hi,
> > >
> > > I want to find out why fd0 is being added to /proc/partitions and stop
> > > that for my build.  I've searched "/proc/partitions" and "partitions",
> > > not finding anything that matters.
> >
> > /proc/partitions is produced on demand by causing a read of it.
> > That is done by these functions (pointers) in block/genhd.c:
> >
> > static const struct seq_operations partitions_op = {
> > .start  = show_partition_start,
> > .next   = disk_seqf_next,
> > .stop   = disk_seqf_stop,
> > .show   = show_partition
> > };
> >
> > in particular, show_partition().  In turn, that function uses data that was
> > produced upon block device discovery, also in block/genhd.c.
> > See functions disk_get_part(), disk_part_iter_init(), disk_part_iter_next(),
> > disk_part_iter_exit(), __device_add_disk(), and get_gendisk().
> >
> > > If udev is doing it, what function is it call so I can search on that?
> >
> > I don't know about that.  I guess in the kernel it is about "uevents".
> > E.g., in block/genhd.c, there are some calls to kobject_uevent() or variants
> > of it.
> >
> > > TIA!!
> >
> > There should be something in your boot log about "fd" or "fd0" or floppy.
> > eh?
> >
> > --
> > ~Randy

Re: What populates /proc/partitions ?

[David F.]

Thanks for the replies.   I'll see if I can figure this out.   I know
with the same kernel and older udev version in use that it didn't add
it, but with the new udev (eudev) it does (one big difference is the
new one requires and uses devtmpfs and the old one didn't).

I tried making the floppy a module but it still loads on vmware player
and the physical test system I'm using that doesn't have one but
reports it as existing (vmware doesn't hang, just adds fd0 read errors
to log, but physical system does hang while fdisk -l, mdadm --scan
runs, etc..).

As far as the log, debugging udev output, it's close to the same, the
message log (busybox) not much in there to say what's up.   I even
tried the old .rules that were being used with the old udev version,
but made no difference.

On Mon, Sep 30, 2019 at 4:49 PM Randy Dunlap  wrote:
>
> On 9/30/19 3:47 PM, David F. wrote:
> > Hi,
> >
> > I want to find out why fd0 is being added to /proc/partitions and stop
> > that for my build.  I've searched "/proc/partitions" and "partitions",
> > not finding anything that matters.
>
> /proc/partitions is produced on demand by causing a read of it.
> That is done by these functions (pointers) in block/genhd.c:
>
> static const struct seq_operations partitions_op = {
> .start  = show_partition_start,
> .next   = disk_seqf_next,
> .stop   = disk_seqf_stop,
> .show   = show_partition
> };
>
> in particular, show_partition().  In turn, that function uses data that was
> produced upon block device discovery, also in block/genhd.c.
> See functions disk_get_part(), disk_part_iter_init(), disk_part_iter_next(),
> disk_part_iter_exit(), __device_add_disk(), and get_gendisk().
>
> > If udev is doing it, what function is it call so I can search on that?
>
> I don't know about that.  I guess in the kernel it is about "uevents".
> E.g., in block/genhd.c, there are some calls to kobject_uevent() or variants
> of it.
>
> > TIA!!
>
> There should be something in your boot log about "fd" or "fd0" or floppy.
> eh?
>
> --
> ~Randy

What populates /proc/partitions ?

[David F.]

Hi,

I want to find out why fd0 is being added to /proc/partitions and stop
that for my build.  I've searched "/proc/partitions" and "partitions",
not finding anything that matters.

If udev is doing it, what function is it call so I can search on that?

TIA!!

Why does /proc/partitions have sr0 and fd0 in it?

[David F.]

Hi,

I was updating some tools such as udev, mdadm, lvm, and came across a
hang and messages about unable to read fd0 which wasn't occurring with
the old tools, but using same kernel.  So I've found that in the old
version the /proc/partitions didn't have fd0 whereas now it does.  But
both have sr0 in it.  So that leads me to who populates the
/proc/partitions, from the limited info you can find searching the
Internet, it looks like the kernel.   But obviously not since same
kernel used with different results.

The difference is the old system udev used the old debian
create_static_nodes and didn't use devtmpfs, the new udev (eudev),
uses devtmpfs and the create_static_nodes is a bash function instead
of separate binary. I wonder if that has something to do with it.

But since cd and floppy devices aren't partitioned traditionally
(technically any block device could be but it would be non-standard)
why are they in the /proc/partitions file (also the device, e.g. sda,
is in there and it's not a partition).   So is it not partitions but
just block devices?   If so, maybe /proc/partitions should be a
symlink to a new /proc/blockdevices, so everyone is clear what
actually goes in there (leave the old name just for backwards
compatibility) ?

Is there any docs on all this?

Thanks!

Re: did vfs_read or something related to it get broken?

[David F.]

Answer: No nothing got broken except the driver itself.

On Fri, Jun 30, 2017 at 4:10 PM, David F. <df7...@gmail.com> wrote:
> Hi,
>
> I have a driver that reads data from a file that has worked from
> kernel 3.x up to 4.9.13.  I haven't tried all the other 4.9's or 4.10,
> or 4.11.6 or earlier, but in 4.11.7 it's now broken and an error is
> returned.   It's based on
> http://krishnamohanlinux.blogspot.com/2013/12/how-to-write-to-file-from-kernel-module.html
>
> Is there a new requirement of some sort or did it get broken?
>
> int driver_file_read(struct file *file, unsigned char *data, unsigned int 
> size)
> {
>   int ret;
>   mm_segment_t oldfs;
>
>   // get file pointer
>   loff_t pos = file->f_pos;
>
>   oldfs   = get_fs();
>   set_fs(get_ds());
>
>   ret=vfs_read(file, data, size, );
>
>   set_fs(oldfs);
>
>   // update file pointer
>   file->f_pos=pos;
>
>return (ret);
> }
>
>
> struct file *driver_file_open(const char *path, int flags, int mode, int *err)
> {
>   int ec=0;
>   struct file *filp = NULL;
>   filp=filp_open(path, flags, mode);
>   if (IS_ERR(filp)) {
> ec=PTR_ERR(filp);
> filp=NULL;
>   }
>   // update callers error code
>   if (err) {
> *err=ec;
>   }
>   // return pointer to file
>   return (filp);
> }

Re: did vfs_read or something related to it get broken?

[David F.]

Answer: No nothing got broken except the driver itself.

On Fri, Jun 30, 2017 at 4:10 PM, David F.  wrote:
> Hi,
>
> I have a driver that reads data from a file that has worked from
> kernel 3.x up to 4.9.13.  I haven't tried all the other 4.9's or 4.10,
> or 4.11.6 or earlier, but in 4.11.7 it's now broken and an error is
> returned.   It's based on
> http://krishnamohanlinux.blogspot.com/2013/12/how-to-write-to-file-from-kernel-module.html
>
> Is there a new requirement of some sort or did it get broken?
>
> int driver_file_read(struct file *file, unsigned char *data, unsigned int 
> size)
> {
>   int ret;
>   mm_segment_t oldfs;
>
>   // get file pointer
>   loff_t pos = file->f_pos;
>
>   oldfs   = get_fs();
>   set_fs(get_ds());
>
>   ret=vfs_read(file, data, size, );
>
>   set_fs(oldfs);
>
>   // update file pointer
>   file->f_pos=pos;
>
>return (ret);
> }
>
>
> struct file *driver_file_open(const char *path, int flags, int mode, int *err)
> {
>   int ec=0;
>   struct file *filp = NULL;
>   filp=filp_open(path, flags, mode);
>   if (IS_ERR(filp)) {
> ec=PTR_ERR(filp);
> filp=NULL;
>   }
>   // update callers error code
>   if (err) {
> *err=ec;
>   }
>   // return pointer to file
>   return (filp);
> }

Pattern of black screens with Linux on newer laptops.

[David F.]

Using up to and including 4.11.7 getting reports coming in of black
screens on new laptops (includes booting to console only).   The
solution is to use kernel parameter acpi=off.  The newer include Dell
Latitude 5289 and  Lenovo e-560. (although searching Internet even
older system affected like HP Envy 17 j053ea and others that
pci=noacpi is enough to get it working).   Be nice for Linux to "just
work" on these systems without special kernel parameters.

Pattern of black screens with Linux on newer laptops.

[David F.]

Using up to and including 4.11.7 getting reports coming in of black
screens on new laptops (includes booting to console only).   The
solution is to use kernel parameter acpi=off.  The newer include Dell
Latitude 5289 and  Lenovo e-560. (although searching Internet even
older system affected like HP Envy 17 j053ea and others that
pci=noacpi is enough to get it working).   Be nice for Linux to "just
work" on these systems without special kernel parameters.

did vfs_read or something related to it get broken?

[David F.]

Hi,

I have a driver that reads data from a file that has worked from
kernel 3.x up to 4.9.13.  I haven't tried all the other 4.9's or 4.10,
or 4.11.6 or earlier, but in 4.11.7 it's now broken and an error is
returned.   It's based on
http://krishnamohanlinux.blogspot.com/2013/12/how-to-write-to-file-from-kernel-module.html

Is there a new requirement of some sort or did it get broken?

int driver_file_read(struct file *file, unsigned char *data, unsigned int size)
{
  int ret;
  mm_segment_t oldfs;

  // get file pointer
  loff_t pos = file->f_pos;

  oldfs   = get_fs();
  set_fs(get_ds());

  ret=vfs_read(file, data, size, );

  set_fs(oldfs);

  // update file pointer
  file->f_pos=pos;

   return (ret);
}


struct file *driver_file_open(const char *path, int flags, int mode, int *err)
{
  int ec=0;
  struct file *filp = NULL;
  filp=filp_open(path, flags, mode);
  if (IS_ERR(filp)) {
ec=PTR_ERR(filp);
filp=NULL;
  }
  // update callers error code
  if (err) {
*err=ec;
  }
  // return pointer to file
  return (filp);
}

did vfs_read or something related to it get broken?

[David F.]

Hi,

I have a driver that reads data from a file that has worked from
kernel 3.x up to 4.9.13.  I haven't tried all the other 4.9's or 4.10,
or 4.11.6 or earlier, but in 4.11.7 it's now broken and an error is
returned.   It's based on
http://krishnamohanlinux.blogspot.com/2013/12/how-to-write-to-file-from-kernel-module.html

Is there a new requirement of some sort or did it get broken?

int driver_file_read(struct file *file, unsigned char *data, unsigned int size)
{
  int ret;
  mm_segment_t oldfs;

  // get file pointer
  loff_t pos = file->f_pos;

  oldfs   = get_fs();
  set_fs(get_ds());

  ret=vfs_read(file, data, size, );

  set_fs(oldfs);

  // update file pointer
  file->f_pos=pos;

   return (ret);
}


struct file *driver_file_open(const char *path, int flags, int mode, int *err)
{
  int ec=0;
  struct file *filp = NULL;
  filp=filp_open(path, flags, mode);
  if (IS_ERR(filp)) {
ec=PTR_ERR(filp);
filp=NULL;
  }
  // update callers error code
  if (err) {
*err=ec;
  }
  // return pointer to file
  return (filp);
}

Re: When will Linux support M2 on RAID ?

[David F.]

Very possible it affects other devices attached, but all consumer
reports and test systems here all have NVME drives on m2 and when in
RAID mode.  Listing PCI data linux will show Intel SATA controller
detected in RAID mode, but no drives detected, all you get is your
/dev/sda USB boot device.  A lot of places linux uses a table of known
ID's and if not listed doesn't support it, unlike Windows which always
supports the given generic device type when it can (keyboard, etc..)
and special drivers for special features.  RAID of course is different
an typically requires special drivers.   As mentioned, some system
don't let you change the mode, others you can't use linux as a
maintenance platform since it won't see any of the drives.  Just be
nice to have things "just work".

On Tue, Mar 7, 2017 at 7:54 AM, Austin S. Hemmelgarn
 wrote:
> On 2017-03-07 10:15, Christoph Hellwig wrote:
>>
>> On Tue, Mar 07, 2017 at 09:50:22AM -0500, Austin S. Hemmelgarn wrote:
>>>
>>> He's referring to the RAID mode most modern Intel chipsets have, which
>>> (last
>>> I checked) Linux does not support completely and many OEM's are setting
>>> by
>>> default on new systems because it apparently provides better performance
>>> than AHCI even for a single device.
>>
>>
>> It actually provides worse performance.  What it does it that it shoves
>> up to three nvme device bars into the bar of an AHCI device, and
>> requires the OS to handle them all using a single driver.  The Money's
>> on crack at Intel decided to do that to provide their "valueable" RSTe
>> IP (which is a windows ATA + RAID driver in a blob, which now has also
>> grown a NVMe driver).  The only remotely sane thing is to disable it
>> in the bios, and burn all people involved with it.  The next best thing
>> is to provide a fake PCIe root port driver untangling this before it
>> hits the driver, but unfortunately Intel is unwilling to either do this
>> on their own or at least provide enough documentation for others to do
>> it.
>>
> For NVMe, yeah, it hurts performance horribly.  For SATA devices though,
> it's hit or miss, some setups perform better, some perform worse.
>
> It does have one advantage though, it lets you put the C drive for a Windows
> install on a soft-RAID array insanely easily compared to trying to do so
> through Windows itself (although still significantly less easily that doing
> the equivalent on Linux...).
>
> The cynic in me is tempted to believe that the OEM's who are turning it on
> by default are trying to either:
> 1. Make their low-end systems look even crappier in terms of performance
> while adding to their marketing checklist (Of the systems I've seen that
> have this on by default, most were cheap ones with really low specs).
> 2. Actively make it harder to run anything but Windows on their hardware.

Re: When will Linux support M2 on RAID ?

[David F.]

Very possible it affects other devices attached, but all consumer
reports and test systems here all have NVME drives on m2 and when in
RAID mode.  Listing PCI data linux will show Intel SATA controller
detected in RAID mode, but no drives detected, all you get is your
/dev/sda USB boot device.  A lot of places linux uses a table of known
ID's and if not listed doesn't support it, unlike Windows which always
supports the given generic device type when it can (keyboard, etc..)
and special drivers for special features.  RAID of course is different
an typically requires special drivers.   As mentioned, some system
don't let you change the mode, others you can't use linux as a
maintenance platform since it won't see any of the drives.  Just be
nice to have things "just work".

On Tue, Mar 7, 2017 at 7:54 AM, Austin S. Hemmelgarn
 wrote:
> On 2017-03-07 10:15, Christoph Hellwig wrote:
>>
>> On Tue, Mar 07, 2017 at 09:50:22AM -0500, Austin S. Hemmelgarn wrote:
>>>
>>> He's referring to the RAID mode most modern Intel chipsets have, which
>>> (last
>>> I checked) Linux does not support completely and many OEM's are setting
>>> by
>>> default on new systems because it apparently provides better performance
>>> than AHCI even for a single device.
>>
>>
>> It actually provides worse performance.  What it does it that it shoves
>> up to three nvme device bars into the bar of an AHCI device, and
>> requires the OS to handle them all using a single driver.  The Money's
>> on crack at Intel decided to do that to provide their "valueable" RSTe
>> IP (which is a windows ATA + RAID driver in a blob, which now has also
>> grown a NVMe driver).  The only remotely sane thing is to disable it
>> in the bios, and burn all people involved with it.  The next best thing
>> is to provide a fake PCIe root port driver untangling this before it
>> hits the driver, but unfortunately Intel is unwilling to either do this
>> on their own or at least provide enough documentation for others to do
>> it.
>>
> For NVMe, yeah, it hurts performance horribly.  For SATA devices though,
> it's hit or miss, some setups perform better, some perform worse.
>
> It does have one advantage though, it lets you put the C drive for a Windows
> install on a soft-RAID array insanely easily compared to trying to do so
> through Windows itself (although still significantly less easily that doing
> the equivalent on Linux...).
>
> The cynic in me is tempted to believe that the OEM's who are turning it on
> by default are trying to either:
> 1. Make their low-end systems look even crappier in terms of performance
> while adding to their marketing checklist (Of the systems I've seen that
> have this on by default, most were cheap ones with really low specs).
> 2. Actively make it harder to run anything but Windows on their hardware.

When will Linux support M2 on RAID ?

[David F.]

More and more systems are coming with M2 on RAID and Linux doesn't
work unless you change the system out of RAID mode.  This is becoming
more and more of a problem.   What is the status of Linux support for
the new systems?

TIA!!

When will Linux support M2 on RAID ?

[David F.]

More and more systems are coming with M2 on RAID and Linux doesn't
work unless you change the system out of RAID mode.  This is becoming
more and more of a problem.   What is the status of Linux support for
the new systems?

TIA!!

NVME M2 devices on RAID configured controllers

[David F.]

More and more system are coming with M2 devices on RAID configured
controllers which Linux does not support.  Switching to AHCI mode
instead of RAID mode allows it to see the drives but that is not a fix
when you want it in RAID mode and want to use Windows as well.   The
question I have is this being worked on?   If not, why isn't it
finding the NVME devices on a controller configured as RAID (Is there
a new PCI class code?)?

In general, MDAdm shouldn't be looking for firmware RAID when the PCI
class isn't in RAID mode, but that's a whole other issue.

Thanks.

NVME M2 devices on RAID configured controllers

[David F.]

More and more system are coming with M2 devices on RAID configured
controllers which Linux does not support.  Switching to AHCI mode
instead of RAID mode allows it to see the drives but that is not a fix
when you want it in RAID mode and want to use Windows as well.   The
question I have is this being worked on?   If not, why isn't it
finding the NVME devices on a controller configured as RAID (Is there
a new PCI class code?)?

In general, MDAdm shouldn't be looking for firmware RAID when the PCI
class isn't in RAID mode, but that's a whole other issue.

Thanks.

Re: 4.3 kernel panics when MMC/SDHC card is inserted on thinkpad

[David F]

On 12/05/2016 04:20 AM, Joerg Roedel wrote:
> Hi David,
> 
> On Sun, Dec 04, 2016 at 06:57:57PM -0600, David F wrote:
>> Aug 19 13:32:20 taz [  156.425627] [ cut here ]
>> Aug 19 13:32:20 taz [  156.428136] kernel BUG at
>> drivers/iommu/intel-iommu.c:3682!
> 
> This BUG_ON triggered because the IOMMU driver can't find a domain for
> the device passed to intel_unmap. This looks like an IOMMU bug, but I am
> not 100% sure yet, because if there is no domain for a device the
> intel_map_page path returns 0 and the intel_unmap function should not be
> called.
> 
> I need a couple of things to track this down. Can you please build a
> kernel with CONFIG_DMA_API_DEBUG=y and boot the kernel with IOMMU
> disabled? Insert and remove an SD-Card with this kernel and send me a
> full dmesg.
> 
> Please also send me the output of 'lspci -v' and a full dmesg with IOMMU
> enabled and the BUG triggered.
> 
> 
> Thanks,
> 
>   Joerg
> 

Hello Joerg,

Thanks for looking at this.

I have attached the output you requested.

I did enable the DMA_API_DEBUG, but I did not notice any additional
output anywhere with this debug enabled. I verified it was enabled
looking at /proc/config.gz. My apologies if I missed something, but
hopefully the output is what you need.


Thanks,
David

# lspci -v

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family 
DRAM Controller (rev 09)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=0c 

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915

00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 (rev 04)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f2525000 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network 
Connection (rev 04)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at f250 (32-bit, non-prefetchable) [size=128K]
Memory at f252b000 (32-bit, non-prefetchable) [size=4K]
I/O ports at 5080 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] PCI Advanced Features
Kernel driver in use: e1000e

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family 
USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 21ce
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at f252a000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci-pci

00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family 
High Definition Audio Controller (rev 04)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at f252 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI 
Express Root Port 1 (rev b4) (prog-if 00 [Normal decode])
Flags: fast devsel
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 2000-2fff
Memory behind bridge: dfa0-dfbf
Prefetchable memory behind bridge: dfc0-dfdf
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: 

Re: 4.3 kernel panics when MMC/SDHC card is inserted on thinkpad

[David F]

On 12/05/2016 04:20 AM, Joerg Roedel wrote:
> Hi David,
> 
> On Sun, Dec 04, 2016 at 06:57:57PM -0600, David F wrote:
>> Aug 19 13:32:20 taz [  156.425627] [ cut here ]
>> Aug 19 13:32:20 taz [  156.428136] kernel BUG at
>> drivers/iommu/intel-iommu.c:3682!
> 
> This BUG_ON triggered because the IOMMU driver can't find a domain for
> the device passed to intel_unmap. This looks like an IOMMU bug, but I am
> not 100% sure yet, because if there is no domain for a device the
> intel_map_page path returns 0 and the intel_unmap function should not be
> called.
> 
> I need a couple of things to track this down. Can you please build a
> kernel with CONFIG_DMA_API_DEBUG=y and boot the kernel with IOMMU
> disabled? Insert and remove an SD-Card with this kernel and send me a
> full dmesg.
> 
> Please also send me the output of 'lspci -v' and a full dmesg with IOMMU
> enabled and the BUG triggered.
> 
> 
> Thanks,
> 
>   Joerg
> 

Hello Joerg,

Thanks for looking at this.

I have attached the output you requested.

I did enable the DMA_API_DEBUG, but I did not notice any additional
output anywhere with this debug enabled. I verified it was enabled
looking at /proc/config.gz. My apologies if I missed something, but
hopefully the output is what you need.


Thanks,
David

# lspci -v

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family 
DRAM Controller (rev 09)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=0c 

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915

00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 (rev 04)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f2525000 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network 
Connection (rev 04)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at f250 (32-bit, non-prefetchable) [size=128K]
Memory at f252b000 (32-bit, non-prefetchable) [size=4K]
I/O ports at 5080 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] PCI Advanced Features
Kernel driver in use: e1000e

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family 
USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 21ce
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at f252a000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci-pci

00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family 
High Definition Audio Controller (rev 04)
Subsystem: Lenovo Device 21ce
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at f252 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI 
Express Root Port 1 (rev b4) (prog-if 00 [Normal decode])
Flags: fast devsel
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 2000-2fff
Memory behind bridge: dfa0-dfbf
Prefetchable memory behind bridge: dfc0-dfdf
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: 

Re: 4.3 kernel panics when MMC/SDHC card is inserted on thinkpad

[David F]

On 16/12/15 09:50, Adrian Hunter wrote:
> 
> 
> On 15/12/15 18:01, Ulf Hansson wrote:
>> +Adrian
>>
>> On 8 November 2015 at 23:05, Denis Bychkov  wrote:
>>> The only started in 4.3 kernel (at least RC-5), 4.2.x does not have
>>> this problem. The kernel panic happens immediately after the SDHC card
>>> is inserted, reproducibility is 100%. If the system boots up with the
>>> card already inserted, it will crash as soon as sdhci_pci module is
>>> loaded. If the module is unloaded/blacklisted, obviously, nothing
>>> happens as the system does not see the MMC card reader.
>>> The machine is Lenovo thinkpad T-510 laptop with Intel Westmere
>>> CPU/3400 series chipset running 64-bit kernel 4.3.0.
>>>
>>
>> Hi Denis,
>>
>> Thanks for reporting and sorry for the delay!
>>
>> Unfortunate, this isn't really my area of expertise and I don't have
>> the HW. In other words, I don't think I will be able to help much.
>>
>> Instead, I am looping in Adrian Hunter, who might be able to have a
>> look at this.
> 
> Have you tried bisecting to find the commit that causes this?
> 

Hello,

I have been experiencing the same panics when inserting SDHC cards.

My environment differs from Denis in the following way:
-Thinkpad T420 with i5-2520M

Apart from that, identical symptoms. Issue still present in 4.9-rc7.

I note that if you disable Intel VT-D in the BIOS, this issue does not
occur.

I ran the requested git bisect today between 4.2 and 4.3-rc1 and it
narrowed down to the following commit:

# git bisect bad
f303e50766298feac17c8715e29ecd14b2c12680 is the first bad commit
commit f303e50766298feac17c8715e29ecd14b2c12680
Author: Joerg Roedel 
Date:   Thu Jul 23 18:37:13 2015 +0200

iommu/vt-d: Avoid duplicate device_domain_info structures

When a 'struct device_domain_info' is created as an alias
for another device, this struct will not be re-used when the
real device is encountered. Fix that to avoid duplicate
device_domain_info structures being added.

Signed-off-by: Joerg Roedel 

:04 04 8f5a7521ef1cdbd8e82b625c5348a1210fe1bf5d
5d2a156956e5cadc9ab35c48b661bbd5fe9d5587 M  drivers


Below is my oops, I apologize if netconsole has formatted it badly:

Aug 19 13:32:20 taz [  156.425627] [ cut here ]
Aug 19 13:32:20 taz [  156.428136] kernel BUG at
drivers/iommu/intel-iommu.c:3682!
Aug 19 13:32:20 taz [  156.430630] invalid opcode:  [#1] PREEMPT SMP
Aug 19 13:32:20 taz [  156.433138] Modules linked in:
Aug 19 13:32:20 taz nf_nat_sip
Aug 19 13:32:20 taz nf_conntrack_sip
Aug 19 13:32:20 taz ebtable_filter
Aug 19 13:32:20 taz ebtables
Aug 19 13:32:20 taz uvcvideo
Aug 19 13:32:20 taz videobuf2_vmalloc
Aug 19 13:32:20 taz videobuf2_memops
Aug 19 13:32:20 taz videobuf2_v4l2
Aug 19 13:32:20 taz videobuf2_core
Aug 19 13:32:20 taz iwldvm
Aug 19 13:32:20 taz mac80211
Aug 19 13:32:20 taz iwlwifi
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.435979] CPU: 0 PID: 0 Comm: swapper/0 Not
tainted 4.7.0-c2h2 #2
Aug 19 13:32:20 taz [  156.438694] Hardware name: LENOVO
4236AR1/4236AR1, BIOS 83ET78WW (1.48 ) 01/21/2016
Aug 19 13:32:20 taz [  156.441423] task: 8260e540 ti:
8260 task.ti: 8260
Aug 19 13:32:20 taz [  156.444155] RIP: 0010:[]
Aug 19 13:32:20 taz [] intel_unmap+0x1f3/0x200
Aug 19 13:32:20 taz [  156.446949] RSP: 0018:88041e203e38  EFLAGS:
00010046
Aug 19 13:32:20 taz [  156.449706] RAX:  RBX:
88040b8fc0a0 RCX: 0a98
Aug 19 13:32:20 taz [  156.452535] RDX:  RSI:
fffec000 RDI: 88040b8fc0a0
Aug 19 13:32:20 taz [  156.455411] RBP: 88041e203e68 R08:
 R09: 0010
Aug 19 13:32:20 taz [  156.458276] R10: 57b750b4 R11:
003b9aca R12: 0001
Aug 19 13:32:20 taz [  156.461125] R13: fffec000 R14:
fffec000 R15: 1000
Aug 19 13:32:20 taz [  156.464001] FS:  ()
GS:88041e20() knlGS:
Aug 19 13:32:20 taz [  156.466936] CS:  0010 DS:  ES:  CR0:
80050033
Aug 19 13:32:20 taz [  156.469913] CR2: 7f02dde4a000 CR3:
02607000 CR4: 000406f0
Aug 19 13:32:20 taz [  156.472917] Stack:
Aug 19 13:32:20 taz [  156.475883]  8800da7308a0
Aug 19 13:32:20 taz 1000
Aug 19 13:32:20 taz 0001
Aug 19 13:32:20 taz 88040b8fc0a0
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.478991]  fffec000
Aug 19 13:32:20 taz 0001
Aug 19 13:32:20 taz 88041e203ea0
Aug 19 13:32:20 taz 816acb5e
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.482132]  8800da730540
Aug 19 13:32:20 taz 88040bdf7cc8
Aug 19 13:32:20 taz 8800da730788
Aug 19 13:32:20 taz 0247
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.485338] Call Trace:
Aug 19 13:32:20 taz [  156.488574]  
Aug 19 13:32:20 taz 156.488574]   ace:
30540a000 CR3: 02607000 CR4: 

Re: 4.3 kernel panics when MMC/SDHC card is inserted on thinkpad

[David F]

On 16/12/15 09:50, Adrian Hunter wrote:
> 
> 
> On 15/12/15 18:01, Ulf Hansson wrote:
>> +Adrian
>>
>> On 8 November 2015 at 23:05, Denis Bychkov  wrote:
>>> The only started in 4.3 kernel (at least RC-5), 4.2.x does not have
>>> this problem. The kernel panic happens immediately after the SDHC card
>>> is inserted, reproducibility is 100%. If the system boots up with the
>>> card already inserted, it will crash as soon as sdhci_pci module is
>>> loaded. If the module is unloaded/blacklisted, obviously, nothing
>>> happens as the system does not see the MMC card reader.
>>> The machine is Lenovo thinkpad T-510 laptop with Intel Westmere
>>> CPU/3400 series chipset running 64-bit kernel 4.3.0.
>>>
>>
>> Hi Denis,
>>
>> Thanks for reporting and sorry for the delay!
>>
>> Unfortunate, this isn't really my area of expertise and I don't have
>> the HW. In other words, I don't think I will be able to help much.
>>
>> Instead, I am looping in Adrian Hunter, who might be able to have a
>> look at this.
> 
> Have you tried bisecting to find the commit that causes this?
> 

Hello,

I have been experiencing the same panics when inserting SDHC cards.

My environment differs from Denis in the following way:
-Thinkpad T420 with i5-2520M

Apart from that, identical symptoms. Issue still present in 4.9-rc7.

I note that if you disable Intel VT-D in the BIOS, this issue does not
occur.

I ran the requested git bisect today between 4.2 and 4.3-rc1 and it
narrowed down to the following commit:

# git bisect bad
f303e50766298feac17c8715e29ecd14b2c12680 is the first bad commit
commit f303e50766298feac17c8715e29ecd14b2c12680
Author: Joerg Roedel 
Date:   Thu Jul 23 18:37:13 2015 +0200

iommu/vt-d: Avoid duplicate device_domain_info structures

When a 'struct device_domain_info' is created as an alias
for another device, this struct will not be re-used when the
real device is encountered. Fix that to avoid duplicate
device_domain_info structures being added.

Signed-off-by: Joerg Roedel 

:04 04 8f5a7521ef1cdbd8e82b625c5348a1210fe1bf5d
5d2a156956e5cadc9ab35c48b661bbd5fe9d5587 M  drivers


Below is my oops, I apologize if netconsole has formatted it badly:

Aug 19 13:32:20 taz [  156.425627] [ cut here ]
Aug 19 13:32:20 taz [  156.428136] kernel BUG at
drivers/iommu/intel-iommu.c:3682!
Aug 19 13:32:20 taz [  156.430630] invalid opcode:  [#1] PREEMPT SMP
Aug 19 13:32:20 taz [  156.433138] Modules linked in:
Aug 19 13:32:20 taz nf_nat_sip
Aug 19 13:32:20 taz nf_conntrack_sip
Aug 19 13:32:20 taz ebtable_filter
Aug 19 13:32:20 taz ebtables
Aug 19 13:32:20 taz uvcvideo
Aug 19 13:32:20 taz videobuf2_vmalloc
Aug 19 13:32:20 taz videobuf2_memops
Aug 19 13:32:20 taz videobuf2_v4l2
Aug 19 13:32:20 taz videobuf2_core
Aug 19 13:32:20 taz iwldvm
Aug 19 13:32:20 taz mac80211
Aug 19 13:32:20 taz iwlwifi
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.435979] CPU: 0 PID: 0 Comm: swapper/0 Not
tainted 4.7.0-c2h2 #2
Aug 19 13:32:20 taz [  156.438694] Hardware name: LENOVO
4236AR1/4236AR1, BIOS 83ET78WW (1.48 ) 01/21/2016
Aug 19 13:32:20 taz [  156.441423] task: 8260e540 ti:
8260 task.ti: 8260
Aug 19 13:32:20 taz [  156.444155] RIP: 0010:[]
Aug 19 13:32:20 taz [] intel_unmap+0x1f3/0x200
Aug 19 13:32:20 taz [  156.446949] RSP: 0018:88041e203e38  EFLAGS:
00010046
Aug 19 13:32:20 taz [  156.449706] RAX:  RBX:
88040b8fc0a0 RCX: 0a98
Aug 19 13:32:20 taz [  156.452535] RDX:  RSI:
fffec000 RDI: 88040b8fc0a0
Aug 19 13:32:20 taz [  156.455411] RBP: 88041e203e68 R08:
 R09: 0010
Aug 19 13:32:20 taz [  156.458276] R10: 57b750b4 R11:
003b9aca R12: 0001
Aug 19 13:32:20 taz [  156.461125] R13: fffec000 R14:
fffec000 R15: 1000
Aug 19 13:32:20 taz [  156.464001] FS:  ()
GS:88041e20() knlGS:
Aug 19 13:32:20 taz [  156.466936] CS:  0010 DS:  ES:  CR0:
80050033
Aug 19 13:32:20 taz [  156.469913] CR2: 7f02dde4a000 CR3:
02607000 CR4: 000406f0
Aug 19 13:32:20 taz [  156.472917] Stack:
Aug 19 13:32:20 taz [  156.475883]  8800da7308a0
Aug 19 13:32:20 taz 1000
Aug 19 13:32:20 taz 0001
Aug 19 13:32:20 taz 88040b8fc0a0
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.478991]  fffec000
Aug 19 13:32:20 taz 0001
Aug 19 13:32:20 taz 88041e203ea0
Aug 19 13:32:20 taz 816acb5e
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.482132]  8800da730540
Aug 19 13:32:20 taz 88040bdf7cc8
Aug 19 13:32:20 taz 8800da730788
Aug 19 13:32:20 taz 0247
Aug 19 13:32:20 taz
Aug 19 13:32:20 taz [  156.485338] Call Trace:
Aug 19 13:32:20 taz [  156.488574]  
Aug 19 13:32:20 taz 156.488574]   ace:
30540a000 CR3: 02607000 CR4: 000406f0
Aug 19 13:32:20 taz [  156.488613]  []

Re: Allowing external modules to run across more configs and distros

[David F.]

To follow up on this, to make the existing version check system
continue to work, it would only check those modules that reference the
"struct modconfigopts", either by way of a compiler option on the
macro, or just recommendation that coder create an external reference
to whatever is needed to make the modversions create a reference to
it.

On Sat, Feb 13, 2016 at 12:13 AM, David F.  wrote:
> After sending the below, I realized that if someone doesn't want to
> have to dereference a pointer it could still be done the same way and
> just omitting the member variable (options).  You would just always
> allocate (sizeof (struct module)+sizeof(struct modconfigopts)) and to
> access the options, use a different macro: #define MOD_OPT(m) ((struct
> modconfigopts*)((m)+1))  --or-- #define MOD_OPT(m) ((struct
> modconfigopts*)((int8_t*)(m)+sizeof(*m)))
> example of when an optional item is reference:
> MOD_OPT(THIS_MODULE)->param_lock
>
> now you don't have any dereferencing of the pointer.
>
>
> On Fri, Feb 12, 2016 at 11:45 PM, David F.  wrote:
>> While creating a linux module that should be usable across a wide
>> array of linux versions and builds, I've run into struct modules
>> (THIS_MODULE) being a problem.  It's the only internal struct accessed
>> as a requirement to struct block_device_operations .owner.   It's a
>> bit annoying for this module to be rejected for nothing it has any
>> interest in using.  So I was thinking of a quick solution but don't
>> want to waste my time if people will resist it (not sure when I'll
>> have time to do it, but should be able to do it quickly once i'd have
>> all the source local).  The idea is:
>>
>> Take all #if defines out of the struct module and place them in a
>> separate struct (struct modconfigopts).  Place a single member
>> variable at the end of struct modules as void * (void *options) to
>> access the options.  Have a single macro to access the options member
>> variable for the internal code that access it (#define MOD_OPT(v)
>> ((struct modconfigopts*)(v)).  So internal code would use
>> module->MOD_OPT(options)->param_lock for example.
>>
>> When the module structure is created, it would initialize the options
>> member variable (the memory allocated (sizeof(struct
>> module)+sizeof(struct modconfigopts)) could be contiguous so it's like
>> one big structure, then cleanup would be the same).
>>
>> Doing this should then allow "external" modules that don't need access
>> to the "internal" config options to continue to load and work across a
>> much greater range of Linux distributions.
>>
>> What do you think?

Re: [Y2038] [RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data type

[David F.]

Frankly if XFS is going to change and break, now would be a good time
to convert from MSBF to LSBF, easy to do and would be much more
efficient on PC's.


On Sat, Feb 13, 2016 at 6:50 AM, Arnd Bergmann  wrote:
> On Saturday 13 February 2016 13:18:32 Dave Chinner wrote:
>> On Fri, Feb 12, 2016 at 01:45:49AM -0800, Deepa Dinamani wrote:
>>
>> This code is all different in the current XFS for-next branch.
>> XFS no longer has it's own internal timestamps - it only uses the
>> timestamps in the struct inode now.
>

Re: Allowing external modules to run across more configs and distros

[David F.]

After sending the below, I realized that if someone doesn't want to
have to dereference a pointer it could still be done the same way and
just omitting the member variable (options).  You would just always
allocate (sizeof (struct module)+sizeof(struct modconfigopts)) and to
access the options, use a different macro: #define MOD_OPT(m) ((struct
modconfigopts*)((m)+1))  --or-- #define MOD_OPT(m) ((struct
modconfigopts*)((int8_t*)(m)+sizeof(*m)))
example of when an optional item is reference:
MOD_OPT(THIS_MODULE)->param_lock

now you don't have any dereferencing of the pointer.


On Fri, Feb 12, 2016 at 11:45 PM, David F.  wrote:
> While creating a linux module that should be usable across a wide
> array of linux versions and builds, I've run into struct modules
> (THIS_MODULE) being a problem.  It's the only internal struct accessed
> as a requirement to struct block_device_operations .owner.   It's a
> bit annoying for this module to be rejected for nothing it has any
> interest in using.  So I was thinking of a quick solution but don't
> want to waste my time if people will resist it (not sure when I'll
> have time to do it, but should be able to do it quickly once i'd have
> all the source local).  The idea is:
>
> Take all #if defines out of the struct module and place them in a
> separate struct (struct modconfigopts).  Place a single member
> variable at the end of struct modules as void * (void *options) to
> access the options.  Have a single macro to access the options member
> variable for the internal code that access it (#define MOD_OPT(v)
> ((struct modconfigopts*)(v)).  So internal code would use
> module->MOD_OPT(options)->param_lock for example.
>
> When the module structure is created, it would initialize the options
> member variable (the memory allocated (sizeof(struct
> module)+sizeof(struct modconfigopts)) could be contiguous so it's like
> one big structure, then cleanup would be the same).
>
> Doing this should then allow "external" modules that don't need access
> to the "internal" config options to continue to load and work across a
> much greater range of Linux distributions.
>
> What do you think?

Re: [Y2038] [RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data type

[David F.]

Frankly if XFS is going to change and break, now would be a good time
to convert from MSBF to LSBF, easy to do and would be much more
efficient on PC's.


On Sat, Feb 13, 2016 at 6:50 AM, Arnd Bergmann  wrote:
> On Saturday 13 February 2016 13:18:32 Dave Chinner wrote:
>> On Fri, Feb 12, 2016 at 01:45:49AM -0800, Deepa Dinamani wrote:
>>
>> This code is all different in the current XFS for-next branch.
>> XFS no longer has it's own internal timestamps - it only uses the
>> timestamps in the struct inode now.
>

Re: Allowing external modules to run across more configs and distros

[David F.]

To follow up on this, to make the existing version check system
continue to work, it would only check those modules that reference the
"struct modconfigopts", either by way of a compiler option on the
macro, or just recommendation that coder create an external reference
to whatever is needed to make the modversions create a reference to
it.

On Sat, Feb 13, 2016 at 12:13 AM, David F. <df7...@gmail.com> wrote:
> After sending the below, I realized that if someone doesn't want to
> have to dereference a pointer it could still be done the same way and
> just omitting the member variable (options).  You would just always
> allocate (sizeof (struct module)+sizeof(struct modconfigopts)) and to
> access the options, use a different macro: #define MOD_OPT(m) ((struct
> modconfigopts*)((m)+1))  --or-- #define MOD_OPT(m) ((struct
> modconfigopts*)((int8_t*)(m)+sizeof(*m)))
> example of when an optional item is reference:
> MOD_OPT(THIS_MODULE)->param_lock
>
> now you don't have any dereferencing of the pointer.
>
>
> On Fri, Feb 12, 2016 at 11:45 PM, David F. <df7...@gmail.com> wrote:
>> While creating a linux module that should be usable across a wide
>> array of linux versions and builds, I've run into struct modules
>> (THIS_MODULE) being a problem.  It's the only internal struct accessed
>> as a requirement to struct block_device_operations .owner.   It's a
>> bit annoying for this module to be rejected for nothing it has any
>> interest in using.  So I was thinking of a quick solution but don't
>> want to waste my time if people will resist it (not sure when I'll
>> have time to do it, but should be able to do it quickly once i'd have
>> all the source local).  The idea is:
>>
>> Take all #if defines out of the struct module and place them in a
>> separate struct (struct modconfigopts).  Place a single member
>> variable at the end of struct modules as void * (void *options) to
>> access the options.  Have a single macro to access the options member
>> variable for the internal code that access it (#define MOD_OPT(v)
>> ((struct modconfigopts*)(v)).  So internal code would use
>> module->MOD_OPT(options)->param_lock for example.
>>
>> When the module structure is created, it would initialize the options
>> member variable (the memory allocated (sizeof(struct
>> module)+sizeof(struct modconfigopts)) could be contiguous so it's like
>> one big structure, then cleanup would be the same).
>>
>> Doing this should then allow "external" modules that don't need access
>> to the "internal" config options to continue to load and work across a
>> much greater range of Linux distributions.
>>
>> What do you think?

Re: Allowing external modules to run across more configs and distros

[David F.]

After sending the below, I realized that if someone doesn't want to
have to dereference a pointer it could still be done the same way and
just omitting the member variable (options).  You would just always
allocate (sizeof (struct module)+sizeof(struct modconfigopts)) and to
access the options, use a different macro: #define MOD_OPT(m) ((struct
modconfigopts*)((m)+1))  --or-- #define MOD_OPT(m) ((struct
modconfigopts*)((int8_t*)(m)+sizeof(*m)))
example of when an optional item is reference:
MOD_OPT(THIS_MODULE)->param_lock

now you don't have any dereferencing of the pointer.


On Fri, Feb 12, 2016 at 11:45 PM, David F. <df7...@gmail.com> wrote:
> While creating a linux module that should be usable across a wide
> array of linux versions and builds, I've run into struct modules
> (THIS_MODULE) being a problem.  It's the only internal struct accessed
> as a requirement to struct block_device_operations .owner.   It's a
> bit annoying for this module to be rejected for nothing it has any
> interest in using.  So I was thinking of a quick solution but don't
> want to waste my time if people will resist it (not sure when I'll
> have time to do it, but should be able to do it quickly once i'd have
> all the source local).  The idea is:
>
> Take all #if defines out of the struct module and place them in a
> separate struct (struct modconfigopts).  Place a single member
> variable at the end of struct modules as void * (void *options) to
> access the options.  Have a single macro to access the options member
> variable for the internal code that access it (#define MOD_OPT(v)
> ((struct modconfigopts*)(v)).  So internal code would use
> module->MOD_OPT(options)->param_lock for example.
>
> When the module structure is created, it would initialize the options
> member variable (the memory allocated (sizeof(struct
> module)+sizeof(struct modconfigopts)) could be contiguous so it's like
> one big structure, then cleanup would be the same).
>
> Doing this should then allow "external" modules that don't need access
> to the "internal" config options to continue to load and work across a
> much greater range of Linux distributions.
>
> What do you think?

Allowing external modules to run across more configs and distros

[David F.]

While creating a linux module that should be usable across a wide
array of linux versions and builds, I've run into struct modules
(THIS_MODULE) being a problem.  It's the only internal struct accessed
as a requirement to struct block_device_operations .owner.   It's a
bit annoying for this module to be rejected for nothing it has any
interest in using.  So I was thinking of a quick solution but don't
want to waste my time if people will resist it (not sure when I'll
have time to do it, but should be able to do it quickly once i'd have
all the source local).  The idea is:

Take all #if defines out of the struct module and place them in a
separate struct (struct modconfigopts).  Place a single member
variable at the end of struct modules as void * (void *options) to
access the options.  Have a single macro to access the options member
variable for the internal code that access it (#define MOD_OPT(v)
((struct modconfigopts*)(v)).  So internal code would use
module->MOD_OPT(options)->param_lock for example.

When the module structure is created, it would initialize the options
member variable (the memory allocated (sizeof(struct
module)+sizeof(struct modconfigopts)) could be contiguous so it's like
one big structure, then cleanup would be the same).

Doing this should then allow "external" modules that don't need access
to the "internal" config options to continue to load and work across a
much greater range of Linux distributions.

What do you think?

Allowing external modules to run across more configs and distros

[David F.]

While creating a linux module that should be usable across a wide
array of linux versions and builds, I've run into struct modules
(THIS_MODULE) being a problem.  It's the only internal struct accessed
as a requirement to struct block_device_operations .owner.   It's a
bit annoying for this module to be rejected for nothing it has any
interest in using.  So I was thinking of a quick solution but don't
want to waste my time if people will resist it (not sure when I'll
have time to do it, but should be able to do it quickly once i'd have
all the source local).  The idea is:

Take all #if defines out of the struct module and place them in a
separate struct (struct modconfigopts).  Place a single member
variable at the end of struct modules as void * (void *options) to
access the options.  Have a single macro to access the options member
variable for the internal code that access it (#define MOD_OPT(v)
((struct modconfigopts*)(v)).  So internal code would use
module->MOD_OPT(options)->param_lock for example.

When the module structure is created, it would initialize the options
member variable (the memory allocated (sizeof(struct
module)+sizeof(struct modconfigopts)) could be contiguous so it's like
one big structure, then cleanup would be the same).

Doing this should then allow "external" modules that don't need access
to the "internal" config options to continue to load and work across a
much greater range of Linux distributions.

What do you think?

Re: patch fix for intel sdd s3500 series on Sil3512 controller

[David F.]

Yes.  The drive was found fine on other controllers I tried it on.

On Mon, Mar 24, 2014 at 8:27 AM, Bartlomiej Zolnierkiewicz
 wrote:
>
> + linux-ide mailing list on Cc:
>
> On Monday, March 24, 2014 02:15:58 PM One Thousand Gnomes wrote:
>> On Sat, 22 Mar 2014 16:32:54 -0700
>> "David F."  wrote:
>>
>> > Hi,
>> >
>> > It appears if nIEN is set all polling type IO fails.   After an
>> > attempt, future non-polled communications also fails.  This patch
>> > allows it to work.  Not sure if any spin lock protection would be
>> > needed or the system already handles the device existence for the
>> > generated irq with polling enabled.  handler already ignored irq if
>> > queued command was polling type.
>>
>> Does it behave plugged into a different controller without the hacks ?
>>
>> Alan
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch fix for intel sdd s3500 series on Sil3512 controller

[David F.]

Yes.  The drive was found fine on other controllers I tried it on.

On Mon, Mar 24, 2014 at 8:27 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 + linux-ide mailing list on Cc:

 On Monday, March 24, 2014 02:15:58 PM One Thousand Gnomes wrote:
 On Sat, 22 Mar 2014 16:32:54 -0700
 David F. df7...@gmail.com wrote:

  Hi,
 
  It appears if nIEN is set all polling type IO fails.   After an
  attempt, future non-polled communications also fails.  This patch
  allows it to work.  Not sure if any spin lock protection would be
  needed or the system already handles the device existence for the
  generated irq with polling enabled.  handler already ignored irq if
  queued command was polling type.

 Does it behave plugged into a different controller without the hacks ?

 Alan

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

patch fix for intel sdd s3500 series on Sil3512 controller

[David F.]

Hi,

It appears if nIEN is set all polling type IO fails.   After an
attempt, future non-polled communications also fails.  This patch
allows it to work.  Not sure if any spin lock protection would be
needed or the system already handles the device existence for the
generated irq with polling enabled.  handler already ignored irq if
queued command was polling type.


fix-sil3512-intelssd.patch
Description: Binary data

patch fix for intel sdd s3500 series on Sil3512 controller

[David F.]

Hi,

It appears if nIEN is set all polling type IO fails.   After an
attempt, future non-polled communications also fails.  This patch
allows it to work.  Not sure if any spin lock protection would be
needed or the system already handles the device existence for the
generated irq with polling enabled.  handler already ignored irq if
queued command was polling type.


fix-sil3512-intelssd.patch
Description: Binary data