Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 1月, 2009 1 次提交
  3. 13 1月, 2009 2 次提交
  5. 12 1月, 2009 1 次提交
    • M
      BUGFIX: used NULL pointer at ioctl(sk,IMGETDEVINFO,&devinfo) when devinfo.id not registered · 57de16e6
      由 Martin Bachem 提交于 
      daxtar example # modprobe hfcsusb
daxtar example # modprobe mISDN_l1loop
daxtar example # ./misdnportinfo
Found 3 devices
        id:             0
        Dprotocols:     00000006
        Bprotocols:     0000000e
        protocol:       0
        nrbchan:        2
        name:           HFC-S_USB.1
        id:             1
        Dprotocols:     00000006
        Bprotocols:     0000000e
        protocol:       0
        nrbchan:        2
        name:           mISDN_l1loop.1
        id:             2
        Dprotocols:     00000006
        Bprotocols:     0000000e
        protocol:       0
        nrbchan:        2
        name:           mISDN_l1loop.2
daxtar example # rmmod hfcsusb
daxtar example # ./misdnportinfo
Found 2 devices
*Segmentation* *fault*

dmesg:

[ 9914.939718] BUG: unable to handle kernel NULL pointer dereference at 000000d4
[ 9914.939721] IP: [<f8f9f2dd>] :mISDN_core:get_mdevice+0x19/0x22
[ 9914.939729] *pde = 00000000
[ 9914.939732] Oops: 0000 [#14] PREEMPT SMP
[ 9914.939734] Modules linked in: mISDN_l1loop mISDN_core vmnet vmblock vmci vmmon coretemp w83627ehf hwmon_vid rfcomm l2cap blue
tooth usbhid snd_usb_audio snd_usb_lib snd_rawmidi snd_hwdep fuse nvidia(P) uhci_hcd i2c_i801 ehci_hcd snd_hda_intel atl1 usbcore i2c_core parport_seria
l [last unloaded: hfcsusb]
[ 9914.939751] Pid: 29618, comm: misdnportinfo Tainted: P      D   (2.6.27.3 #5)
[ 9914.939753] EIP: 0060:[<f8f9f2dd>] EFLAGS: 00210246 CPU: 0
[ 9914.939758] EIP is at get_mdevice+0x19/0x22 [mISDN_core]
[ 9914.939760] EAX: 00000000 EBX: f8fa791c ECX: f6afaa58 EDX: f7960cf4
[ 9914.939762] ESI: 80044944 EDI: bfc2e62c EBP: bfc2e62c ESP: f5adbef4
[ 9914.939763]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 9914.939765] Process misdnportinfo (pid: 29618, ti=f5ada000 task=f6bec430 task.ti=f5ada000)
[ 9914.939767] Stack: f8f9f4e0 00000000 f8f9f867 bfc2e62c 0000000a c02461e8 00200246 c042dde8
[ 9914.939771]        00000003 c042dde4 00000000 00000001 00200082 c0114775 00000000 00000000
[ 9914.939775]        00000003 f7088010 00200282 f8fa791c 80044944 bfc2e62c bfc2e62c c02f6615
[ 9914.939780] Call Trace:
[ 9914.939782]  [<f8f9f4e0>] _get_mdevice+0x0/0x18 [mISDN_core]
[ 9914.939789]  [<f8f9f867>] base_sock_ioctl+0x7a/0x129 [mISDN_core]
[ 9914.939789]  [<c02461e8>] opost+0x171/0x182
[ 9914.939789]  [<c0114775>] __wake_up+0x29/0x39
[ 9914.939789]  [<c02f6615>] sock_ioctl+0x1b5/0x1d9
[ 9914.939789]  [<c02f6460>] sock_ioctl+0x0/0x1d9
[ 9914.939789]  [<c016794c>] vfs_ioctl+0x1c/0x5d
[ 9914.939789]  [<c0167bcb>] do_vfs_ioctl+0x23e/0x24e
[ 9914.939789]  [<c0167c07>] sys_ioctl+0x2c/0x45
[ 9914.939789]  [<c0102cbd>] sysenter_do_call+0x12/0x21
[ 9914.939789]  [<c0350000>] pci_fixup_i450gx+0x4e/0x56
[ 9914.939789]  =======================
[ 9914.939789] Code: 00 68 02 f0 f9 f8 e8 ae b4 2c c7 8b 44 24 04 5a 59 c3 83 ec 04 31 d2 89 04 24 89 e1 b8 ac df fa f8 68 e0 f4
f9 f8 e8 4a b5 2c c7 <8b> 80 d4 00 00 00 5a 59 c3 53 89 cb 8d 90 9c 00 00 00 89 c8 e8
[ 9914.939789] EIP: [<f8f9f2dd>] get_mdevice+0x19/0x22 [mISDN_core] SS:ESP 0068:f5adbef4
[ 9914.939858] ---[ end trace 50e18a715b019424 ]---
Signed-off-by: NMartin Bachem <m.bachem@gmx.de>
Signed-off-by: NKarsten Keil <kkeil@suse.de>
      57de16e6
  7. 11 1月, 2009 9 次提交
  9. 10 1月, 2009 18 次提交
  11. 09 1月, 2009 9 次提交
    • W
      [MTD] CFI: remove major/minor version check for command set 0x0002 · fefae48b
      由 Wolfgang Grandegger 提交于 
      The NOR Flash memory K8P2815UQB from Samsung uses the major version
number '0'. Add a quirk to cope with it.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      fefae48b
    • L
      ACPICA: hide private headers · e2f7a777
      由 Len Brown 提交于 
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e2f7a777
    • Z
      ACPI : Use RSDT instead of XSDT by adding boot option of "acpi=rsdt" · 237889bf
      由 Zhao Yakui 提交于 
      On some boxes there exist both RSDT and XSDT table. But unfortunately
sometimes there exists the following error when XSDT table is used:
   a. 32/64X address mismatch
   b. The 32/64X FACS address mismatch

   In such case the boot option of "acpi=rsdt" is provided so that
RSDT is tried instead of XSDT table when the system can't work well.

http://bugzilla.kernel.org/show_bug.cgi?id=8246Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
cc:Thomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>
      237889bf
    • L
      ACPICA: delete acdisasm.h · 5b929aa1
      由 Len Brown 提交于 
      it is referenced only #ifdef ACPI_DISASSEMBLER,
which is never set by the kernel.
Signed-off-by: NLen Brown <len.brown@intel.com>
      5b929aa1
    • A
      libata: Add 32bit PIO support · 871af121
      由 Alan Cox 提交于 
      This matters for some controllers and in one or two cases almost doubles
PIO performance. Add a bmdma32 operations set we can inherit and activate
it for some controllers
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      871af121
    • N
      md: don't retry recovery of raid1 that fails due to error on source drive. · 4044ba58
      由 NeilBrown 提交于 
      If a raid1 has only one working drive and it has a sector which
gives an error on read, then an attempt to recover onto a spare will
fail, but as the single remaining drive is not removed from the
array, the recovery will be immediately re-attempted, resulting
in an infinite recovery loop.

So detect this situation and don't retry recovery once an error
on the lone remaining drive is detected.

Allow recovery to be retried once every time a spare is added
in case the problem wasn't actually a media error.
Signed-off-by: NNeilBrown <neilb@suse.de>
      4044ba58
    • N
      md: Allow md devices to be created by name. · efeb53c0
      由 NeilBrown 提交于 
      Using sequential numbers to identify md devices is somewhat artificial.
Using names can be a lot more user-friendly.

Also, creating md devices by opening the device special file is a bit
awkward.

So this patch provides a new option for creating and naming devices.

Writing a name such as "md_home" to
    /sys/modules/md_mod/parameters/new_array
will cause an array with that name to be created.  It will appear in
/sys/block/ /proc/partitions and /proc/mdstat as 'md_home'.
It will have an arbitrary minor number allocated.

md devices that a created by an open are destroyed on the last
close when the device is inactive.
For named md devices, they will not be destroyed until the array
is explicitly stopped, either with the STOP_ARRAY ioctl or by
writing 'clear' to /sys/block/md_XXXX/md/array_state.

The name of the array must start 'md_' to avoid conflict with
other devices.
Signed-off-by: NNeilBrown <neilb@suse.de>
      efeb53c0
    • N
      md: make devices disappear when they are no longer needed. · d3374825
      由 NeilBrown 提交于 
      Currently md devices, once created, never disappear until the module
is unloaded.  This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.

If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed.  However it
is not possible to hook into the gendisk destruction process to enable
this.

So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed.  However this has a
complication.
Between the call
   __blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
   __blkdev_get->md_open

there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.

Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created.  We need to
ensure that this reference can not be used.  i.e. the ->open must
fail.

So:
 1/  in md_probe we set a flag in the mddev (hold_active) which
     indicates that the array should be treated as active, even
     though there are no references, and no appearance of activity.
     This is cleared by md_release when the device is closed if it
     is no longer needed.
     This ensures that the gendisk will survive between md_probe and
     md_open.

 2/  In md_open we check if the mddev we expect to open matches
     the gendisk that we did open.
     If there is a mismatch we return -ERESTARTSYS and modify
     __blkdev_get to retry from the top in that case.
     In the -ERESTARTSYS sys case we make sure to wait until
     the old gendisk (that we succeeded in opening) is really gone so
     we loop at most once.

Some udev configurations will always open an md device when it first
appears.   If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it.  This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).

As an array can be stopped by writing to a sysfs attribute
  echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects.  This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NNeilBrown <neilb@suse.de>
      d3374825
    • C
      md: need another print_sb for mdp_superblock_1 · cd2ac932
      由 Cheng Renquan 提交于 
      md_print_devices is called in two code path: MD_BUG(...), and md_ioctl
with PRINT_RAID_DEBUG.  it will dump out all in use md devices
information;

However, it wrongly processed two types of superblock in one:

The header file <linux/raid/md_p.h> has defined two types of superblock,
struct mdp_superblock_s (typedefed with mdp_super_t) according to md with
metadata 0.90, and struct mdp_superblock_1 according to md with metadata
1.0 and later,

These two types of superblock are very different,

The md_print_devices code processed them both in mdp_super_t, that would
lead to wrong informaton dump like:

	[ 6742.345877]
	[ 6742.345887] md:	**********************************
	[ 6742.345890] md:	* <COMPLETE RAID STATE PRINTOUT> *
	[ 6742.345892] md:	**********************************
	[ 6742.345896] md1: <ram7><ram6><ram5><ram4>
	[ 6742.345907] md: rdev ram7, SZ:00065472 F:0 S:1 DN:3
	[ 6742.345909] md: rdev superblock:
	[ 6742.345914] md:  SB: (V:0.90.0) ID:<42ef13c7.598c059a.5f9f1645.801e9ee6> CT:4919856d
	[ 6742.345918] md:     L5 S00065472 ND:4 RD:4 md1 LO:2 CS:65536
	[ 6742.345922] md:     UT:4919856d ST:1 AD:4 WD:4 FD:0 SD:0 CSUM:b7992907 E:00000001
	[ 6742.345924]      D  0:  DISK<N:0,(1,8),R:0,S:6>
	[ 6742.345930]      D  1:  DISK<N:1,(1,10),R:1,S:6>
	[ 6742.345933]      D  2:  DISK<N:2,(1,12),R:2,S:6>
	[ 6742.345937]      D  3:  DISK<N:3,(1,14),R:3,S:6>
	[ 6742.345942] md:     THIS:  DISK<N:3,(1,14),R:3,S:6>
	...
	[ 6742.346058] md0: <ram3><ram2><ram1><ram0>
	[ 6742.346067] md: rdev ram3, SZ:00065472 F:0 S:1 DN:3
	[ 6742.346070] md: rdev superblock:
	[ 6742.346073] md:  SB: (V:1.0.0) ID:<369aad81.00000000.00000000.00000000> CT:9a322a9c
	[ 6742.346077] md:     L-1507699579 S976570180 ND:48 RD:0 md0 LO:65536 CS:196610
	[ 6742.346081] md:     UT:00000018 ST:0 AD:131048 WD:0 FD:8 SD:0 CSUM:00000000 E:00000000
	[ 6742.346084]      D  0:  DISK<N:-1,(-1,-1),R:-1,S:-1>
	[ 6742.346089]      D  1:  DISK<N:-1,(-1,-1),R:-1,S:-1>
	[ 6742.346092]      D  2:  DISK<N:-1,(-1,-1),R:-1,S:-1>
	[ 6742.346096]      D  3:  DISK<N:-1,(-1,-1),R:-1,S:-1>
	[ 6742.346102] md:     THIS:  DISK<N:0,(0,0),R:0,S:0>
	...
	[ 6742.346219] md:	**********************************
	[ 6742.346221]

Here md1 is metadata 0.90.0, and md0 is metadata 1.2

After some more code to distinguish these two types of superblock, in this patch,

it will generate dump information like:

	[ 7906.755790]
	[ 7906.755799] md:	**********************************
	[ 7906.755802] md:	* <COMPLETE RAID STATE PRINTOUT> *
	[ 7906.755804] md:	**********************************
	[ 7906.755808] md1: <ram7><ram6><ram5><ram4>
	[ 7906.755819] md: rdev ram7, SZ:00065472 F:0 S:1 DN:3
	[ 7906.755821] md: rdev superblock (MJ:0):
	[ 7906.755826] md:  SB: (V:0.90.0) ID:<3fca7a0d.a612bfed.5f9f1645.801e9ee6> CT:491989f3
	[ 7906.755830] md:     L5 S00065472 ND:4 RD:4 md1 LO:2 CS:65536
	[ 7906.755834] md:     UT:491989f3 ST:1 AD:4 WD:4 FD:0 SD:0 CSUM:00fb52ad E:00000001
	[ 7906.755836]      D  0:  DISK<N:0,(1,8),R:0,S:6>
	[ 7906.755842]      D  1:  DISK<N:1,(1,10),R:1,S:6>
	[ 7906.755845]      D  2:  DISK<N:2,(1,12),R:2,S:6>
	[ 7906.755849]      D  3:  DISK<N:3,(1,14),R:3,S:6>
	[ 7906.755855] md:     THIS:  DISK<N:3,(1,14),R:3,S:6>
	...
	[ 7906.755972] md0: <ram3><ram2><ram1><ram0>
	[ 7906.755981] md: rdev ram3, SZ:00065472 F:0 S:1 DN:3
	[ 7906.755984] md: rdev superblock (MJ:1):
	[ 7906.755989] md:  SB: (V:1) (F:0) Array-ID:<5fbcf158:55aa:5fbe:9a79:1e939880dcbd>
	[ 7906.755990] md:    Name: "DG5:0" CT:1226410480
	[ 7906.755998] md:       L5 SZ130944 RD:4 LO:2 CS:128 DO:24 DS:131048 SO:8 RO:0
	[ 7906.755999] md:     Dev:00000003 UUID: 9194d744:87f7:a448:85f2:7497b84ce30a
	[ 7906.756001] md:       (F:0) UT:1226410480 Events:0 ResyncOffset:-1 CSUM:0dbcd829
	[ 7906.756003] md:         (MaxDev:384)
	...
	[ 7906.756113] md:	**********************************
	[ 7906.756116]

this md0 (metadata 1.2) information dumping is exactly according to struct
mdp_superblock_1.
Signed-off-by: NCheng Renquan <crquan@gmail.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Dan Williams <dan.j.williams@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NNeilBrown <neilb@suse.de>
      cd2ac932