Re: [PATCH] no need to check for NULL before calling kfree() - fs/ext2/
Hi, On Fri, 25 Mar 2005 17:29:56 -0500 (EST), linux-os <[EMAIL PROTECTED]> wrote: > Isn't it expensive of CPU time to call kfree() even though the > pointer may have already been freed? I suggest that the check > for a NULL before the call is much less expensive than calling > kfree() and doing the check there. The resulting "double check" > is cheap, compared to the call. Resource release paths are usually not performance critical. However, if removing the redundant checks introduce a _measurable_ regressions in terms of performance, we can make kfree() inline which will take care of it. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH scsi-misc-2.6 08/08] scsi: fix hot unplug sequence
On Fri, 25 Mar 2005, James Bottomley wrote: > On Fri, 2005-03-25 at 14:38 +0900, Tejun Heo wrote: > > We have users of scsi_do_req() other than scsi_wait_req() and they > > use different done() functions to do different things. I've checked > > other done functions and none uses contents inside the passed > > scsi_cmnd, so using a dummy command should be okay with them. Am I > > missing something here? > > Well ... the other users are supposed to be going away. They're > actually all coded wrongly in some way or other ... perhaps I should > speed up the process. > I have seen you mention this several times now and I am getting more and more worried. The reason is that scsi_wait_req() is a synchronous interface and it does not allow a driver to do this: - send a request - do other useful things/let the user do useful work - wait for completion before starting another request I fully agree that doing done() correctly _is_ a problem, especially when the SCSI subsystem evolves and the high-level driver writers do not follow the development closely enough. One solution to these problems would be to let the drivers still use scsi_do_req() and their own done() function, but create two (three) helpers: - one to be called at the beginning of done(); it would do what needs to be done here but lets the driver to do some special things of its own if necessary - one to be called to wait for the request to finish (- one to do scsi_ro_req() and the things necessary before these) Having these helpers would isolate the user of the SCSI subsystem from the internals. scsi_wait_req() should call these functions and no additional maintenance would be needed for this additional asynchronous interface. The current drivers may not do any work in done() that could not be done later but there is one patch pending where this happens: the st performance statistics patch needs to get the time stamp when the SCSI command is processed. -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.12-rc1-mm3
On Fri, Mar 25, 2005 at 11:12:39PM -0500, Len Brown wrote: > I realize now I didn't answer your original question. > The reason ACPI now depends on PM is that > it makes it easier for us to do a more orderly shutdown -- > acpi registers as a device so it can do some stuff > upon the PM device shutdowns -- before interrupts are disabled. > > I think with all the twisty turney passages > related to the suspend states, poweroff, sys-req, and now kexec, > that it is best if we can keep the code paths as > common as possible or some of them will never get the > testing needed to prevent them from getting broken. > > Also, it is now common practice to include PM && ACPI together > in the x86 world. Though technically one could have > ACPI w/o PM and you'd have lost only ACPI_SLEEP, virtually > nobody seems to use/depend-on that combination. OK, that makes sense. I see now that Jesse has already sent a patch to allow CONFIG_PM on sn2, so we'll be fine as soon as that gets merged. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.30-rc2
Hi,
Here goes the second release candidate for v2.4.30.
It contains a bunch of security updates (ext2 mkdir leak, af_bluetooth range
checking, isofs corrupt media, load_elf_library DoS), an ia64 update, another
round of networking fixes, amongst others.
If nothing terrible shows up, this will become v2.4.30.
Please help with testing!
Summary of changes from v2.4.30-rc1 to v2.4.30-rc2
:
o [TG3]: Add missing CHIPREV_5750_{A,B}X defines
o [TG3]: Missing counter bump in tigon3_4gb_hwbug_workaround()
o [TG3]: Update driver version and reldate
:
o eepro100: fix module parameter description typo
:
o CAN-2005-0400: ext2 mkdir() directory entry random kernel memory leak
:
o fs/hpfs/*: fix HPFS support under 64-bit kernel
:
o [NETFILTER]: Fix another DECLARE_MUTEX in header file
Bjorn Helgaas:
o ia64: force all kernel sections into one and the same segment
o ia64: round iommu allocations to power-of-two sizes
o ia64: fix perfmon typo in /proc/pal/CPU*/processor_info w.r.t. BERR
o ia64: add missing syscall-slot
o ia64: Update defconfigs
Chris Wright:
o isofs: Some more defensive checks to keep corrupt isofs images from
corrupting memory/oopsing
Dave Kleikamp:
o JFS: remove aops from directory inodes
David Mosberger:
o Fix pte_modify() bug which allowed mprotect() to change too many bits
o ia64: Fix _PAGE_CHG_MASK so PROT_NONE works again. Caught by Linus
Greg Banks:
o link_path_walk refcount problem allows umount of active filesystem
Herbert Xu:
o [CRYPTO]: Mark myself as co-maintainer
o [NETLINK]: Fix multicast bind/autobind race
o CAN-2005-0794: Potential DOS in load_elf_library
Keith Owens:
o [IA64] Sanity check unw_unwind_to_user
o [IA64] Tighten up unw_unwind_to_user check
Linus Torvalds:
o isofs: Handle corupted rock-ridge info slightly better
o isofs: more "corrupted iso image" error cases
Marcel Holtmann:
o CAN-2005-0750: Fix af_bluetooth range checking bug, discovered by Ilja van
Sprundel <[EMAIL PROTECTED]>
Marcelo Tosatti:
o Change VERSION to 2.4.30-rc2
Michael Chan:
o [TG3]: Add 5705_plus flag
o [TG3]: Flush status block in tg3_interrupt()
o [TG3]: Add unstable PLL workaround for 5750
o [TG3]: Fix jumbo frames phy settings
o [TG3]: Fix ethtool set functions
o [TG3]: Add Broadcom copyright
Neil Brown:
o nlm: fix f_count leak
o [PATCH md: allow degraded raid1 array to resync after an unclean shutdown
Pablo Neira:
o [NETFILTER]: Fix DECLARE_MUTEX in header file
Patrick McHardy:
o [NETFILTER]: fix return values of ipt_recent checkentry
o [NETFILTER]: Fix ip_ct_selective_cleanup(), and rename
ip_ct_iterate_cleanup()
o [NETFILTER]: Fix cleanup in ipt_recent
o [NETFILTER]: Fix ip6tables ESP matching with "-p all"
o [NETFILTER]: Fix refreshing of overlapping expectations
o [NETFILTER]: Fix IP/TCP option logging
o [TUN]: Fix check for underflow
Pete Zaitcev:
o USB: fix oops in serial_write
o USB: Fix baud selection in mct_u232
Simon Horman:
o [IPVS]: Fix comment typos
o Backport v2.6 ATM copy-to-user signedness fix
o earlyquirk.o is needed for CONFIG_ACPI_BOOT
Stephen Hemminger:
o [TCP]: BIC not binary searching correctly
Wensong Zhang:
o [IPVS]: Update mark->cw in the WRR scheduler while service is updated
Yanmin Zhang:
o [IA64] clean up ptrace corner cases
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH libata-dev-2.6] sata_sil: updated mod15write workaround
Hello, Jeff.
This is the updated version of mod15write workaround. Changes are
* sg list restoration on completion
* debug code to verify sg list doesn't get changed
* updated against the latest libata-dev-2.6
* more comments
I think the code is okay, but I left the debug code there just in
case. The debug code is inside #ifdef and can be removed easily once
testing is complete.
Thanks.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/26 14:16:23+09:00 [EMAIL PROTECTED]
# cosmetic
#
# drivers/scsi/sata_sil.c
# 2005/03/26 14:13:44+09:00 [EMAIL PROTECTED] +17 -4
# xxx
#
# ChangeSet
# 2005/03/26 12:32:07+09:00 [EMAIL PROTECTED]
# Merge htj.dyndns.org:/mnt/tj-work/os/ata/libata-dev-2.6
# into htj.dyndns.org:/mnt/tj-work/os/ata/libata-work
#
# drivers/scsi/sata_sil.c
# 2005/03/26 12:32:01+09:00 [EMAIL PROTECTED] +0 -0
# Auto merged
#
# ChangeSet
# 2005/03/26 12:29:29+09:00 [EMAIL PROTECTED]
# sg restoration implemented
# M15W_DEBUG
#
# drivers/scsi/sata_sil.c
# 2005/03/26 12:29:21+09:00 [EMAIL PROTECTED] +54 -2
# sg restoration implemented
# M15W_DEBUG
#
# ChangeSet
# 2005/03/16 08:45:47+09:00 [EMAIL PROTECTED]
# comments
#
# drivers/scsi/sata_sil.c
# 2005/03/16 08:45:39+09:00 [EMAIL PROTECTED] +36 -10
# comments
#
# ChangeSet
# 2005/03/16 02:14:47+09:00 [EMAIL PROTECTED]
# m15w workaround works now
#
# drivers/scsi/sata_sil.c
# 2005/03/16 02:14:40+09:00 [EMAIL PROTECTED] +54 -25
# m15w workaround works now
#
# ChangeSet
# 2005/03/15 22:16:44+09:00 [EMAIL PROTECTED]
# xxx
#
# drivers/scsi/sata_sil.c
# 2005/03/15 22:16:35+09:00 [EMAIL PROTECTED] +89 -36
# xxx
#
# ChangeSet
# 2005/03/15 16:36:29+09:00 [EMAIL PROTECTED]
# initial implementaion of mod15write workaround
#
# drivers/scsi/sata_sil.c
# 2005/03/15 16:36:21+09:00 [EMAIL PROTECTED] +139 -11
# initial implementaion of mod15write workaround
#
diff -Nru a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
--- a/drivers/scsi/sata_sil.c 2005-03-26 14:17:50 +09:00
+++ b/drivers/scsi/sata_sil.c 2005-03-26 14:17:50 +09:00
@@ -71,9 +71,12 @@
static int sil_init_one (struct pci_dev *pdev, const struct pci_device_id
*ent);
static void sil_dev_config(struct ata_port *ap, struct ata_device *dev);
+static void sil_qc_prep (struct ata_queued_cmd *qc);
+static void sil_eng_timeout (struct ata_port *ap);
static u32 sil_scr_read (struct ata_port *ap, unsigned int sc_reg);
static void sil_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val);
static void sil_post_set_mode (struct ata_port *ap);
+static void sil_host_stop (struct ata_host_set *host_set);
static struct pci_device_id sil_pci_tbl[] = {
{ 0x1095, 0x3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sil_3112 },
@@ -151,15 +154,16 @@
.bmdma_start= ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
.bmdma_status = ata_bmdma_status,
- .qc_prep= ata_qc_prep,
+ .qc_prep= sil_qc_prep,
.qc_issue = ata_qc_issue_prot,
- .eng_timeout= ata_eng_timeout,
+ .eng_timeout= sil_eng_timeout,
.irq_handler= ata_interrupt,
.irq_clear = ata_bmdma_irq_clear,
.scr_read = sil_scr_read,
.scr_write = sil_scr_write,
.port_start = ata_port_start,
.port_stop = ata_port_stop,
+ .host_stop = sil_host_stop,
};
static struct ata_port_info sil_port_info[] = {
@@ -202,6 +206,53 @@
/* ... port 3 */
};
+/*
+ * Context to loop over write requests > 15 sectors for Mod15Write bug.
+ *
+ * The following libata layer fields are saved at the beginning and
+ * mangled as necessary.
+ *
+ * qc->sg : To fool ata_fill_sg().
+ * qc->n_elem : ditto.
+ * qc->flags : Except for the last iteration, ATA_QCFLAG_DMAMAP
+ * should be off on entering ata_interrupt() such
+ * that ata_qc_complete() doesn't call ata_sg_clean()
+ * before sil_m15w_chunk_complete(), but the flags
+ * should be set for ata_qc_prep() to work. This flag
+ * handling is the hackiest part of this workaround.
+ * qc->complete_fn : Overrided to sil_m15w_chunk_complete().
+ *
+ * The following cxt fields are used to iterate over write requests.
+ *
+ * next_block : The starting block of the next chunk.
+ * next_sg : The first sg entry of the next chunk.
+ * left: Total bytes left.
+ * cur_sg_ofs : Number of processed bytes in the first sg entry
+ * of this chunk.
+ * next_sg_ofs : Number of bytes to be processed in the last sg
+ * entry of this chunk.
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-10
On Fri, 2005-03-25 at 23:39 +0100, Ingo Molnar wrote:
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote:
> > > i have released the -V0.7.41-10 Real-Time Preemption patch, which can be
> > > downloaded from the usual place:
> > >
> > >http://redhat.com/~mingo/realtime-preempt/
> >
> > I get zillions of "return type defaults to int" warnings trying to
> > compile this with PREEMPT_DESKTOP.
>
> i've uploaded -41-11 which should fix it.
>
OK. Any idea about those get_swap_page latencies? I set the swappiness
to 100 on both machines, but I only see those on the slower machine.
Running for several days with PREEMPT_DESKTOP, on the Athlon XP the
worst latency I am seeing is ~150 usecs! But on the C3 its about 4ms:
( ksoftirqd/0-2|#0): new 16 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 32 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 77 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 86 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 110 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 121 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 131 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 136 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 143 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 172 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 594 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 1164 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 1255 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 1429 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 1557 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 1680 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 1722 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 1944 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2027 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2082 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2107 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2112 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2322 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2339 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2426 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2517 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2707 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2817 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 2874 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3053 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3149 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3225 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3250 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3316 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3636 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3668 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3819 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3953 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 3964 us maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 4104 us maximum-latency wakeup.
The traces look like this:
preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-08
latency: 4104 us, #124/124, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0) kswapd066 0 9 0002 [0061867425992692] 0.000ms
(+914240.345ms): <6177736b> (<00306470>)
(T1/#2) kswapd066 0 9 0002 0002 [0061867425993150] 0.000ms
(+0.000ms): __trace_start_sched_wakeup+0x96/0xc0
(try_to_wake_up+0x84/0x140 )
(T1/#3) kswapd066 0 9 0003 [0061867425993646] 0.001ms
(+0.001ms): wake_up_process+0x1c/0x30 (do_softirq+0x4b/0x60
)
(T6/#4) kswapd0-660dn.22us!< (1)
(T2/#5) kswapd0-660dnh2 975us : do_IRQ+0x2d/0x80 (c014e3c6 0 0)
(T1/#6) kswapd066 0 5 0001 0006 [0061867426579669] 0.976ms
(+0.003ms): mask_and_ack_8259A+0xb/0x110 (__do_IRQ+0x8b/0x160
)
(T1/#7) kswapd066 0 5 0001 0007 [0061867426581623] 0.979ms
(+0.000ms): redirect_hardirq+0x8/0x90 (__do_IRQ+0xbc/0x160
)
(T1/#8) kswapd066 0 5 0008
Re: [0/12] More Driver Model Locking Changes
On Fri, Mar 25, 2005 at 04:03:09PM -0800, Greg KH wrote:
>
> Oh, looks like pci express now has problems too, I'll go hit that one
> next...
Here's a fix for pci express. For some reason I don't think they are
using the driver model properly here, but I could be wrong...
thanks,
greg k-h
[pcie] use device_for_each_child() to properly access child devices.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
diff -Nru a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
--- a/drivers/pci/pcie/portdrv_core.c 2005-03-25 20:44:04 -08:00
+++ b/drivers/pci/pcie/portdrv_core.c 2005-03-25 20:44:04 -08:00
@@ -232,9 +232,6 @@
/* Initialize generic device interface */
device = >device;
memset(device, 0, sizeof(struct device));
- INIT_LIST_HEAD(>node);
- INIT_LIST_HEAD(>children);
- INIT_LIST_HEAD(>bus_list);
device->bus = _port_bus_type;
device->driver = NULL;
device->driver_data = NULL;
@@ -317,84 +314,71 @@
}
#ifdef CONFIG_PM
-int pcie_port_device_suspend(struct pci_dev *dev, u32 state)
+
+static int suspend_iter(struct device *dev, void *data)
{
- struct list_head*head, *tmp;
- struct device *parent, *child;
- struct device_driver*driver;
struct pcie_port_service_driver *service_driver;
+ u32 state = (u32)data;
- parent = >dev;
- head = >children;
- tmp = head->next;
- while (head != tmp) {
- child = container_of(tmp, struct device, node);
- tmp = tmp->next;
- if (child->bus != _port_bus_type)
- continue;
- driver = child->driver;
- if (!driver)
- continue;
- service_driver = to_service_driver(driver);
- if (service_driver->suspend)
- service_driver->suspend(to_pcie_device(child), state);
+ if ((dev->bus == _port_bus_type) &&
+ (dev->driver)) {
+ service_driver = to_service_driver(dev->driver);
+ if (service_driver->suspend)
+ service_driver->suspend(to_pcie_device(dev), state);
}
+ return 0;
+}
+
+int pcie_port_device_suspend(struct pci_dev *dev, u32 state)
+{
+ device_for_each_child(>dev, (void *)state, suspend_iter);
return 0;
}
-int pcie_port_device_resume(struct pci_dev *dev)
-{
- struct list_head*head, *tmp;
- struct device *parent, *child;
- struct device_driver*driver;
+static int resume_iter(struct device *dev, void *data)
+{
struct pcie_port_service_driver *service_driver;
- parent = >dev;
- head = >children;
- tmp = head->next;
- while (head != tmp) {
- child = container_of(tmp, struct device, node);
- tmp = tmp->next;
- if (child->bus != _port_bus_type)
- continue;
- driver = child->driver;
- if (!driver)
- continue;
- service_driver = to_service_driver(driver);
- if (service_driver->resume)
- service_driver->resume(to_pcie_device(child));
+ if ((dev->bus == _port_bus_type) &&
+ (dev->driver)) {
+ service_driver = to_service_driver(dev->driver);
+ if (service_driver->resume)
+ service_driver->resume(to_pcie_device(dev));
}
- return 0;
+ return 0;
+}
+int pcie_port_device_resume(struct pci_dev *dev)
+{
+ device_for_each_child(>dev, NULL, resume_iter);
+ return 0;
}
#endif
-void pcie_port_device_remove(struct pci_dev *dev)
+static int remove_iter(struct device *dev, void *data)
{
- struct list_head*head, *tmp;
- struct device *parent, *child;
- struct device_driver*driver;
struct pcie_port_service_driver *service_driver;
- int interrupt_mode = PCIE_PORT_INTx_MODE;
+ int *interrupt_mode = data;
- parent = >dev;
- head = >children;
- tmp = head->next;
- while (head != tmp) {
- child = container_of(tmp, struct device, node);
- tmp = tmp->next;
- if (child->bus != _port_bus_type)
- continue;
- driver = child->driver;
- if (driver) {
- service_driver = to_service_driver(driver);
+ if (dev->bus == _port_bus_type) {
+ if (dev->driver) {
+ service_driver = to_service_driver(dev->driver);
if (service_driver->remove)
- service_driver->remove(to_pcie_device(child));
+ service_driver->remove(to_pcie_device(dev));
}
-
Re: [RFC] CryptoAPI & Compression
Hi Artem:
On Fri, Mar 25, 2005 at 04:08:20PM +, Artem B. Bityuckiy wrote:
>
> I'm working on cleaning-up the JFFS3 compression stuff. JFFS3 contains a
> number of compressors which actually shouldn't be there as they are
> platform-independent and generic. So we want to move them to the generic
> part of the Linux kernel instead of storing them in fs/jffs2/. And we
> were going to use CryptoAPI to access the compressors.
Sounds good.
> In JFFS2 we need something more flexible. Te following is what we want:
>
> int crypto_compress_ext(struct crypto_tfm *tfm,
> const u8 *src, unsigned int *slen,
> u8 *dst, unsigned int *dlen);
Compressing part of the input could be significantly different from
compressing all of the input depending on the algorithm. In particular
it could be most costly to do so and/or result in worse compression.
So while I'm happy to add such an interface I think we should keep
crypto_comp_compress as well for full compression.
I've whipped up something quick and called it crypto_comp_pcompress.
How does this interface look to you?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
= crypto/compress.c 1.7 vs edited =
--- 1.7/crypto/compress.c 2003-03-29 22:16:58 +11:00
+++ edited/crypto/compress.c2005-03-26 15:33:19 +11:00
@@ -18,6 +18,17 @@
#include
#include "internal.h"
+static int crypto_pcompress(struct crypto_tfm *tfm,
+ const u8 *src, unsigned int *slen,
+ u8 *dst, unsigned int *dlen)
+{
+ if (!tfm->__crt_alg->cra_compress.coa_pcompress)
+ return -ENOSYS;
+ return tfm->__crt_alg->cra_compress.coa_pcompress(crypto_tfm_ctx(tfm),
+ src, slen, dst,
+ dlen);
+}
+
static int crypto_compress(struct crypto_tfm *tfm,
const u8 *src, unsigned int slen,
u8 *dst, unsigned int *dlen)
@@ -50,6 +61,7 @@
if (ret)
goto out;
+ ops->cot_pcompress = crypto_pcompress;
ops->cot_compress = crypto_compress;
ops->cot_decompress = crypto_decompress;
= include/linux/crypto.h 1.32 vs edited =
--- 1.32/include/linux/crypto.h 2005-01-26 16:53:19 +11:00
+++ edited/include/linux/crypto.h 2005-03-26 15:25:39 +11:00
@@ -87,6 +87,8 @@
struct compress_alg {
int (*coa_init)(void *ctx);
void (*coa_exit)(void *ctx);
+ int (*coa_pcompress)(void *ctx, const u8 *src, unsigned int *slen,
+u8 *dst, unsigned int *dlen);
int (*coa_compress)(void *ctx, const u8 *src, unsigned int slen,
u8 *dst, unsigned int *dlen);
int (*coa_decompress)(void *ctx, const u8 *src, unsigned int slen,
@@ -178,6 +180,9 @@
};
struct compress_tfm {
+ int (*cot_pcompress)(struct crypto_tfm *tfm,
+const u8 *src, unsigned int *slen,
+u8 *dst, unsigned int *dlen);
int (*cot_compress)(struct crypto_tfm *tfm,
const u8 *src, unsigned int slen,
u8 *dst, unsigned int *dlen);
@@ -363,6 +368,14 @@
{
BUG_ON(crypto_tfm_alg_type(tfm) != CRYPTO_ALG_TYPE_CIPHER);
memcpy(dst, tfm->crt_cipher.cit_iv, len);
+}
+
+static inline int crypto_comp_pcompress(struct crypto_tfm *tfm,
+ const u8 *src, unsigned int *slen,
+ u8 *dst, unsigned int *dlen)
+{
+ BUG_ON(crypto_tfm_alg_type(tfm) != CRYPTO_ALG_TYPE_COMPRESS);
+ return tfm->crt_compress.cot_pcompress(tfm, src, slen, dst, dlen);
}
static inline int crypto_comp_compress(struct crypto_tfm *tfm,
Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Fri, 25 Mar 2005 20:50:35 +0100, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls > > > ./ ../ device@ > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l > > > Segmentation fault > > > > What device is that, and which driver is handling it? > > If I am allowed a wild guess here... Isn't by any chance i2c-1 one the > the 3 i2c adapters exported by the nvidiafb driver, which we know isn't > playing nicely with the i2c core? To me, it is simply a different > expression of the same bug Miles hit some days ago when loading the > i2c-dev or eeprom modules [1]. You are exactly right. The /sys issues had to do with i2c stuff associated the nvidiafb driver. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3
Something funky going on with ACPI on nForce2? NFS is no go either. Linux version 2.6.12-rc1-mm3 ([EMAIL PROTECTED]) (gcc version 3.3.4) #2 PREEMPT Fri Mar 25 14:30:56 EST 2005 [snip ...] ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 PCI: nForce2 C1 Halt Disconnect fixup Boot video device is :03:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:00.1 ACPI: Can't get handler for :00:00.2 ACPI: Can't get handler for :00:00.3 ACPI: Can't get handler for :00:00.4 ACPI: Can't get handler for :00:00.5 ACPI: Can't get handler for :01:0a.0 ACPI: Can't get handler for :01:0b.0 ACPI: Can't get handler for :01:0c.0 ACPI: Can't get handler for :03:00.1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled. ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled. ACPI: PCI Interrupt Link [APC4] (IRQs *19), disabled. ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled. ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled. ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: No ACPI bus support for 00:00 ACPI: No ACPI bus support for 00:01 ACPI: No ACPI bus support for 00:02 ACPI: No ACPI bus support for 00:03 ACPI: No ACPI bus support for 00:04 ACPI: No ACPI bus support for 00:05 ACPI: No ACPI bus support for 00:06 ACPI: No ACPI bus support for 00:07 ACPI: No ACPI bus support for 00:08 ACPI: No ACPI bus support for 00:09 ACPI: No ACPI bus support for 00:0a ACPI: No ACPI bus support for 00:0b ACPI: No ACPI bus support for 00:0c ACPI: No ACPI bus support for 00:0d pnp: PnP ACPI: found 14 devices PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:00: ioport range 0x1000-0x107f could not be reserved pnp: 00:00: ioport range 0x1080-0x10ff has been reserved pnp: 00:00: ioport range 0x1400-0x147f has been reserved pnp: 00:00: ioport range 0x1480-0x14ff could not be reserved pnp: 00:00: ioport range 0x1800-0x187f has been reserved pnp: 00:00: ioport range 0x1880-0x18ff has been reserved pnp: 00:01: ioport range 0x1c00-0x1c3f has been reserved pnp: 00:01: ioport range 0x2000-0x203f has been reserved ACPI: Power Button (FF) [PWRF] PNP: PS/2 controller doesn't have AUX irq; using default 0xc PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 112 ACPI: No ACPI bus support for i8042 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ACPI: No ACPI bus support for serial8250 ACPI: No ACPI bus support for serio0 ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ACPI: No ACPI bus support for serio1 ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [snip ...] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ACPI: No ACPI bus support for 0.0 ACPI: No ACPI bus
Re: [ACPI] Re: 2.6.12-rc1-mm3
On Fri, 2005-03-25 at 21:57, Jason Uhlenkott wrote: > On Fri, Mar 25, 2005 at 09:24:21PM -0500, Len Brown wrote: > > What bad things happen if you define CONFIG_PM on SN2? > > None, other than slightly enlarging the kernel with some > suspend/resume stuff we don't care about. It's always been > unavailable for SN2 builds: > > depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || > IA64_HP_ZX1_SWIOTLB > > but there doesn't appear to be any particular reason for that other > than us not needing it (and in fact SN2 systems can run IA64_GENERIC > kernels with CONFIG_PM enabled without incident). good. I realize now I didn't answer your original question. The reason ACPI now depends on PM is that it makes it easier for us to do a more orderly shutdown -- acpi registers as a device so it can do some stuff upon the PM device shutdowns -- before interrupts are disabled. I think with all the twisty turney passages related to the suspend states, poweroff, sys-req, and now kexec, that it is best if we can keep the code paths as common as possible or some of them will never get the testing needed to prevent them from getting broken. Also, it is now common practice to include PM && ACPI together in the x86 world. Though technically one could have ACPI w/o PM and you'd have lost only ACPI_SLEEP, virtually nobody seems to use/depend-on that combination. Obviously I hadn't considered SN2 or built its config before that 1-liner. I'll be sure to build it next time. > > Re: CONFIG_ACPI_BOOT > > I've got a patch that makes it go away -- this looks like > > a good reason for me to dust it off... Looks like > > arch/ia64/Kconfig defines ACPI and then pulls in > drivers/acpi/Kconfig, > > which it should not do - it should look like i386/Kconfig... > > Sounds good to me. Does that mean everything currently controlled by > CONFIG_ACPI_BOOT will be controlled by CONFIG_ACPI instead? yes. this was in -mm a while back, but got pushed onto the back burner when more pressing things came up. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.6
* Hua Zhong ([EMAIL PROTECTED]) wrote:
> > int bt_sock_unregister(int proto)
> > {
> > - if (proto >= BT_MAX_PROTO)
> > + if (proto < 0 || proto >= BT_MAX_PROTO)
> > return -EINVAL;
>
> Just curious: would it be better to say
>
> if ((unsigned int)proto >= BT_MAX_PTORO)
the first check makes it painfully obvious what it's checking. i think
it's a wash (-O2 seems to collapse to the same check), with a win for
readability.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Squashfs without ./..
H. Peter Anvin wrote: Phil Lougher wrote: Making readdir return '.' and '..' is trivially easy, as all the required information to fake '.' and '..' entries are present. The lack of '.' and '..' entries hasn't caused any problems despite cramfs/squashfs being used for a large number of years. I'm inclined to believe any application that _relies_ on seeing '.' and '..' returned by readdir is broken. This situation is easily fixed within the application rather than forcing the filesystem to unnecessarily fake '.' and '..' entries which are never used. Yeah, let's fix every broken application on the planet instead of fixing it in one place... Fixing it in Squashfs implies Squashfs is broken. It isn't. If it has to be "fixed" in the kenel, fix it in the VFS, it is after all the VFS which makes '.' and '..' handling redundant in the filesystem. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.6
On Mar 25, 2005, at 22:47, Hua Zhong wrote:
int bt_sock_unregister(int proto)
{
- if (proto >= BT_MAX_PROTO)
+ if (proto < 0 || proto >= BT_MAX_PROTO)
return -EINVAL;
Just curious: would it be better to say
if ((unsigned int)proto >= BT_MAX_PTORO)
Erm, it _would_ work, but it's _much_ less clear, less typesafe,
and besides, GCC can probably optimize that test anyways.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r
!y?(-)
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [0/12] More Driver Model Locking Changes
On Fri, Mar 25, 2005 at 06:24:58PM -0800, Patrick Mochel wrote: > On Fri, 25 Mar 2005, Greg KH wrote: > > Oh, looks like pci express now has problems too, I'll go hit that one > > next... > > Bah, sorry about that. What config are you using to test, 'allmodconfig'? Yup. Looks like pci express is doing some odd stuff, I'll go fix that up now. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Squashfs without ./..
Phil Lougher wrote: Making readdir return '.' and '..' is trivially easy, as all the required information to fake '.' and '..' entries are present. The lack of '.' and '..' entries hasn't caused any problems despite cramfs/squashfs being used for a large number of years. I'm inclined to believe any application that _relies_ on seeing '.' and '..' returned by readdir is broken. This situation is easily fixed within the application rather than forcing the filesystem to unnecessarily fake '.' and '..' entries which are never used. Yeah, let's fix every broken application on the planet instead of fixing it in one place... -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] - MPT FUSION - SPLITTING SCSI HOST DRIVERS
On Thu, 2005-03-24 at 16:57 -0700, Moore, Eric Dean wrote:
> +static struct device_attribute mptscsih_queue_depth_attr = {
> + .attr = {
> + .name = "queue_depth",
> + .mode = S_IWUSR,
> + },
> + .store = mpt_core_store_queue_depth,
> +};
But in the original which you're removing, this was implemented via the
change_queue_depth API.
It looks like the patches you're posting are actually an older version
of the fusion driver. Do you have the split done on a current copy?
Thanks,
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Squashfs without ./..
On Thu, 24 Mar 2005 15:13:08 -0500, Kyle Moffett <[EMAIL PROTECTED]> wrote: > I would add ".." and "." to squashfs, just so that it acts like the rest > of the filesystems on the planet, Cramfs also doesn't store '.' and '..', which is where I got the idea from in the first place when originally implementing Squashfs. Filesystems don't need to store '.' or ''..' in the filesystem, as they're never looked up by the VFS - as mentioned elsewhere in this thread, the VFS handles '.' and '..' internally. Not storing the redundant '.' and '..' entries within the filesystem achieves a small but nonetheless useful space saving. > even if it has to emulate them > internally. Making readdir return '.' and '..' is trivially easy, as all the required information to fake '.' and '..' entries are present. The lack of '.' and '..' entries hasn't caused any problems despite cramfs/squashfs being used for a large number of years. I'm inclined to believe any application that _relies_ on seeing '.' and '..' returned by readdir is broken. This situation is easily fixed within the application rather than forcing the filesystem to unnecessarily fake '.' and '..' entries which are never used. > OTOH, I think that the default behavior of find is broken > and should probably be fixed, maybe by making the default use the full > readdir and optionally allowing a -fast option that optimizes the > search using such tricks. > Cramfs/Squashfs and other filesystems set the link count on files and directories to 1, find correctly interprets this to mean it can't do any of its 'tricks' and doesn't use any optimisations. Phillip - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 2.6.11.6
> int bt_sock_unregister(int proto)
> {
> - if (proto >= BT_MAX_PROTO)
> + if (proto < 0 || proto >= BT_MAX_PROTO)
> return -EINVAL;
Just curious: would it be better to say
if ((unsigned int)proto >= BT_MAX_PTORO)
?
Is it faster too?
Hua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.12-rc1-mm3
On Friday, March 25, 2005 6:57 pm, Jason Uhlenkott wrote: > On Fri, Mar 25, 2005 at 09:24:21PM -0500, Len Brown wrote: > > What bad things happen if you define CONFIG_PM on SN2? > > None, other than slightly enlarging the kernel with some > suspend/resume stuff we don't care about. It's always been > unavailable for SN2 builds: > > depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB > > but there doesn't appear to be any particular reason for that other > than us not needing it (and in fact SN2 systems can run IA64_GENERIC > kernels with CONFIG_PM enabled without incident). > > > Re: CONFIG_ACPI_BOOT > > I've got a patch that makes it go away -- this looks like > > a good reason for me to dust it off... Looks like > > arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig, > > which it should not do - it should look like i386/Kconfig... Yeah, I noticed that too. If you've got a patch to clean it up, we should go ahead and get it sent off to Tony. I sent this to linux-ia64 the other day to address these issues. Jesse = arch/ia64/Kconfig 1.85 vs edited = --- 1.85/arch/ia64/Kconfig 2005-01-28 15:32:25 -08:00 +++ edited/arch/ia64/Kconfig 2005-03-21 09:38:29 -08:00 @@ -328,7 +328,7 @@ config PM bool "Power Management support" - depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB + depends on !IA64_HP_SIM default y help "Power Management" means that parts of your computer are shut
Re: Linux 2.6.11.6
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2005-03-25 18:26:00 -08:00
+++ b/Makefile 2005-03-25 18:26:00 -08:00
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 11
-EXTRAVERSION = .5
+EXTRAVERSION = .6
NAME=Woozy Numbat
# *DOCUMENTATION*
diff -Nru a/fs/binfmt_elf.c b/fs/binfmt_elf.c
--- a/fs/binfmt_elf.c 2005-03-25 18:26:00 -08:00
+++ b/fs/binfmt_elf.c 2005-03-25 18:26:00 -08:00
@@ -1008,6 +1008,7 @@
static int load_elf_library(struct file *file)
{
struct elf_phdr *elf_phdata;
+ struct elf_phdr *eppnt;
unsigned long elf_bss, bss, len;
int retval, error, i, j;
struct elfhdr elf_ex;
@@ -1031,44 +1032,47 @@
/* j < ELF_MIN_ALIGN because elf_ex.e_phnum <= 2 */
error = -ENOMEM;
- elf_phdata = (struct elf_phdr *) kmalloc(j, GFP_KERNEL);
+ elf_phdata = kmalloc(j, GFP_KERNEL);
if (!elf_phdata)
goto out;
+ eppnt = elf_phdata;
error = -ENOEXEC;
- retval = kernel_read(file, elf_ex.e_phoff, (char *) elf_phdata, j);
+ retval = kernel_read(file, elf_ex.e_phoff, (char *)eppnt, j);
if (retval != j)
goto out_free_ph;
for (j = 0, i = 0; ip_type == PT_LOAD) j++;
+ if ((eppnt + i)->p_type == PT_LOAD)
+ j++;
if (j != 1)
goto out_free_ph;
- while (elf_phdata->p_type != PT_LOAD) elf_phdata++;
+ while (eppnt->p_type != PT_LOAD)
+ eppnt++;
/* Now use mmap to map the library into memory. */
down_write(>mm->mmap_sem);
error = do_mmap(file,
- ELF_PAGESTART(elf_phdata->p_vaddr),
- (elf_phdata->p_filesz +
-ELF_PAGEOFFSET(elf_phdata->p_vaddr)),
+ ELF_PAGESTART(eppnt->p_vaddr),
+ (eppnt->p_filesz +
+ELF_PAGEOFFSET(eppnt->p_vaddr)),
PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE,
- (elf_phdata->p_offset -
-ELF_PAGEOFFSET(elf_phdata->p_vaddr)));
+ (eppnt->p_offset -
+ELF_PAGEOFFSET(eppnt->p_vaddr)));
up_write(>mm->mmap_sem);
- if (error != ELF_PAGESTART(elf_phdata->p_vaddr))
+ if (error != ELF_PAGESTART(eppnt->p_vaddr))
goto out_free_ph;
- elf_bss = elf_phdata->p_vaddr + elf_phdata->p_filesz;
+ elf_bss = eppnt->p_vaddr + eppnt->p_filesz;
if (padzero(elf_bss)) {
error = -EFAULT;
goto out_free_ph;
}
- len = ELF_PAGESTART(elf_phdata->p_filesz + elf_phdata->p_vaddr +
ELF_MIN_ALIGN - 1);
- bss = elf_phdata->p_memsz + elf_phdata->p_vaddr;
+ len = ELF_PAGESTART(eppnt->p_filesz + eppnt->p_vaddr + ELF_MIN_ALIGN -
1);
+ bss = eppnt->p_memsz + eppnt->p_vaddr;
if (bss > len) {
down_write(>mm->mmap_sem);
do_brk(len, bss - len);
diff -Nru a/fs/ext2/dir.c b/fs/ext2/dir.c
--- a/fs/ext2/dir.c 2005-03-25 18:26:00 -08:00
+++ b/fs/ext2/dir.c 2005-03-25 18:26:00 -08:00
@@ -592,6 +592,7 @@
goto fail;
}
kaddr = kmap_atomic(page, KM_USER0);
+ memset(kaddr, 0, chunk_size);
de = (struct ext2_dir_entry_2 *)kaddr;
de->name_len = 1;
de->rec_len = cpu_to_le16(EXT2_DIR_REC_LEN(1));
diff -Nru a/fs/isofs/inode.c b/fs/isofs/inode.c
--- a/fs/isofs/inode.c 2005-03-25 18:26:00 -08:00
+++ b/fs/isofs/inode.c 2005-03-25 18:26:00 -08:00
@@ -685,6 +685,8 @@
sbi->s_log_zone_size = isonum_723 (h_pri->logical_block_size);
sbi->s_max_size = isonum_733(h_pri->volume_space_size);
} else {
+ if (!pri)
+ goto out_freebh;
rootp = (struct iso_directory_record *) pri->root_directory_record;
sbi->s_nzones = isonum_733 (pri->volume_space_size);
sbi->s_log_zone_size = isonum_723 (pri->logical_block_size);
@@ -1394,6 +1396,9 @@
unsigned long hashval;
struct inode *inode;
struct isofs_iget5_callback_data data;
+
+ if (offset >= 1ul << sb->s_blocksize_bits)
+ return NULL;
data.block = block;
data.offset = offset;
diff -Nru a/fs/isofs/rock.c b/fs/isofs/rock.c
--- a/fs/isofs/rock.c 2005-03-25 18:26:00 -08:00
+++ b/fs/isofs/rock.c 2005-03-25 18:26:00 -08:00
@@ -53,6 +53,7 @@
if(LEN & 1) LEN++; \
CHR = ((unsigned char *) DE) + LEN; \
LEN = *((unsigned char *) DE) - LEN; \
+ if (LEN<0) LEN=0; \
if (ISOFS_SB(inode->i_sb)->s_rock_offset!=-1)\
{ \
LEN-=ISOFS_SB(inode->i_sb)->s_rock_offset;\
@@ -73,6
Linux 2.6.11.6
With some pending security fixes it's time to for a -stable update. So, here's 2.6.11.6, in the normal kernel.org places. This includes some security fixes, esp. one which closes a local root exploit in bluetooth. The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch between 2.6.11.5 and 2.6.11.6, as it is small enough to do so. thanks, -chris -- Makefile |2 +- fs/binfmt_elf.c | 30 +- fs/ext2/dir.c|1 + fs/isofs/inode.c |5 + fs/isofs/rock.c | 25 ++--- net/bluetooth/af_bluetooth.c |6 +++--- 6 files changed, 45 insertions(+), 24 deletions(-) Summary of changes from v2.6.11.5 to v2.6.11.6 == Chris Wright: o isofs: more defensive checks against corrupt isofs images o Linux 2.6.11.6 Herbert Xu: o Potential DOS in load_elf_library Linus Torvalds: o isofs: Handle corupted rock-ridge info slightly better o isofs: more "corrupted iso image" error cases Marcel Holtmann: o Fix signedness problem at socket creation Mathieu Lafon: o Suspected information leak (mem pages) in ext2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] - MPT FUSION - SPLITTING SCSI HOST DRIVERS
On Thu, 2005-03-24 at 16:56 -0700, Moore, Eric Dean wrote: > + > config FUSION_FC > - tristate "Fusion MPT (base + ScsiHost) drivers for FC" > - depends on PCI && SCSI > + tristate "Fusion MPT (ScsiHost) drivers for FC" This rejects completely in Kconfig. Could you check your base for the diffs ... there's no FUSION_FC parameter in the vanilla kernel. Thanks, James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][trivial] fix tiny spelling error in init/Kconfig
Jesper Juhl wrote: Fix spelling in init/Kconfig Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.12-rc1-mm3-orig/init/Kconfig 2005-03-25 15:29:08.0 +0100 +++ linux-2.6.12-rc1-mm3/init/Kconfig 2005-03-26 02:24:33.0 +0100 @@ -83,7 +83,7 @@ default y help This option allows you to choose whether you want to have support - for socalled swap devices or swap files in your kernel that are + for so called swap devices or swap files in your kernel that are used to provide more virtual memory than the actual RAM present in your computer. If unsure say Y. I would prefer (and write) "so-called". -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.6.11.5 doesn't recognize Plextor 712 SATA DVD burner
Hi everybody, I have a stock 2.6.11.5 kernel configured for SATA (libata), which sees my SATA hard drive but not my SATA DVD burner. My system is a dual Opteron 244 running an SMP kernel. The motherboard is MSI K8T Master2 FAR. I have only been successful in getting the SATA DVD burner to work if I enable *both* libata and the deprecated/conflicting support for SATA in the kernel configuration GUI, but the result does not work reliably. The SATA DVD burner becomes unaccessible after a while, requiring a reboot. In my most recent attempt to make this work, I disabled the deprecated SATA support, enabled libata, and put in #define ATA_ENABLE_ATAPI (removed the corresponding #undef) in libata.h prior to recompiling the kernel. This didn't allow me to see the SATA DVD either. I read a post somewhere on the Internet which suggested that this had worked for someone. I am at a loss as to how to proceed to make the SATA DVD burner function, and I'm hoping that someone will be able to help. Here is some (hopefully) useful information. Please let me know if you need more info, and I'd be happy to provide it. I'm also willing to experiment with kernel patches if necessary. Please reply directly to me as I do not subscribe to the list. >From /proc/scsi/scsi: Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: MAXTOR Model: ATLAS10K5_73WLS Rev: JNX0 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: TOSHIBA Model: DVD-ROM SD-M1401 Rev: 1009 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: Seagate Model: STT2NRev: 7A61 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: Maxtor 6B200S0 Rev: BANC Type: Direct-AccessANSI SCSI revision: 05 >From dmesg: libata version 1.10 loaded. sata_via version 1.1 ACPI: PCI interrupt :00:0f.0[B] -> GSI 11 (level, low) -> IRQ 11 sata_via(:00:0f.0): routed to hard irq line 11 ata1: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 11 ata2: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 11 ata1: dev 0 cfg 49:0f00 82: 83: 84: 85: 86: 87: 88:0007 ata1: dev 0 ATAPI, max UDMA/33 ata1: dev 0 configured for UDMA/33 scsi1 : sata_via ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4043 85:7c69 86:3e01 87:4043 88:407f ata2: dev 0 ATA, max UDMA/133, 398297088 sectors: lba48 ata2: dev 0 configured for UDMA/133 scsi2 : sata_via ata1: command 0xa0 timeout, stat 0xd0 host_stat 0x1 Vendor: ATA Model: Maxtor 6B200S0Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdb: 398297088 512-byte hdwr sectors (203928 MB) SCSI device sdb: drive cache: write back SCSI device sdb: 398297088 512-byte hdwr sectors (203928 MB) SCSI device sdb: drive cache: write back sdb: sdb1 Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0 >From lspci: :00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] :00:07.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) :00:0b.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet (rev 03) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) :00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration :00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller :00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control :00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration :00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map :00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller :00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] Thanks in advance for your help. Andy -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA, USA http://www.wlug.org - To unsubscribe from this list: send the line "unsubscribe
Re: [RFC][PATCH 1/4] create mm/Kconfig for arch-independent memory options
Dave Hansen wrote: With sparsemem and memory hotplug there are quite a few options that we kept adding identically in several different architectures. This new file allows some of these to be consolidated. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Signed-off-by: Dave Hansen <[EMAIL PROTECTED]> --- memhotplug-dave/mm/Kconfig | 41 + 1 files changed, 41 insertions(+) diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-03-25 08:08:22.0 -0800 +++ memhotplug-dave/mm/Kconfig 2005-03-25 08:08:22.0 -0800 @@ -0,0 +1,41 @@ +choice + prompt "Memory model" + default FLATMEM + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT + +config FLATMEM + bool "Flat Memory" + depends on !ARCH_DISCONTIGMEM_ENABLE || ARCH_FLATMEM_ENABLE + help + This option allows you to change some of the ways that + Linux manages its memory internally. Most users will + only have one option here: FLATMEM. This is normal + and a correct option. + + Some users of more advanced features like NUMA and + memory hotplug may have different options here. + DISCONTIGMEM is an more mature, better tested system, + but is incompatible with memory hotplug and may suffer + decreased performance over SPARSEMEM. If unsure between + "Sparse Memory" and "Discontiguous Memory", choose Where is the "Sparse Memory" option? I didn't find it. + "Discontiguous Memory". + + If unsure, choose FLATMEM. + +config DISCONTIGMEM + bool "Discontigious Memory" + depends on ARCH_DISCONTIGMEM_ENABLE + help + If unsure, choose this option over "Sparse Memory". Same question +endchoice + +# +# Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's +# to represent different areas of memory. This variable allows +# those dependencies to exist individually. +# +config NEED_MULTIPLE_NODES + def_bool y + depends on DISCONTIGMEM || NUMA -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.12-rc1-mm3
On Fri, Mar 25, 2005 at 09:24:21PM -0500, Len Brown wrote: > What bad things happen if you define CONFIG_PM on SN2? None, other than slightly enlarging the kernel with some suspend/resume stuff we don't care about. It's always been unavailable for SN2 builds: depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB but there doesn't appear to be any particular reason for that other than us not needing it (and in fact SN2 systems can run IA64_GENERIC kernels with CONFIG_PM enabled without incident). > Re: CONFIG_ACPI_BOOT > I've got a patch that makes it go away -- this looks like > a good reason for me to dust it off... Looks like > arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig, > which it should not do - it should look like i386/Kconfig... Sounds good to me. Does that mean everything currently controlled by CONFIG_ACPI_BOOT will be controlled by CONFIG_ACPI instead? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] get rid of a single else clause in cifsfs.c
Hi Steve,
Just a small patch on top of the other ones I sent you earlier for
cifsfs.c, I overlooked this trivial bit.
We can get rid of the else clause in a if statement. Doesn't change
anything code-wise, but shortens the file a bit and seems a bit cleaner
(at least to me) - apply or not as you please of course.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3/fs/cifs/cifsfs.c.with_patch4 2005-03-25
18:03:49.0 +0100
+++ linux-2.6.12-rc1-mm3/fs/cifs/cifsfs.c 2005-03-26 03:41:29.0
+0100
@@ -96,9 +96,8 @@ static int cifs_read_super(struct super_
cifs_sb = CIFS_SB(sb);
if (cifs_sb == NULL)
return -ENOMEM;
- else
- memset(cifs_sb,0,sizeof(struct cifs_sb_info));
+ memset(cifs_sb,0,sizeof(struct cifs_sb_info));
rc = cifs_mount(sb, cifs_sb, data, devname);
if (rc) {
if (!silent)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Squashfs without ./..
> Yep, check `-noleaf' in find(1). No. At least the copy of find that I just looked at now, in findutils-4.1.20, makes no such assumption that "." and ".." are the first two directory entries. Rather what it does is allow you to suppress an optimization, on file systems that don't manage their directory link counts so that the link count on a directory is exactly two more than the number of child directories, which optimization avoids stat'ing every entry if you are using some set of find options that are only looking at names, not other stat data, and if by the link count on the directory, you've already stat'd all the child directories. The documentation for find -noleaf spells this out. The find command is enabling you to adapt to differing file system directory link counts with this option. It is not brokenly forcing a wrong assumption on you, and in any case, it is an issue of directory link counts, not of the opendir-readdir order of "." and ".." (if present). -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech MX1000 Horizontal Scrolling
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > I'm still thinking about what to do with it. You still thinking?. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:esben-stien.name - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.12-rc1-mm3: still having USB resume problems
Though it looks a lot better; no more streams of messages. Now when I resume, I get: PCI: Enabling device :00:1d.7 ( -> 0002) <1>Unable to handle kernel NULL pointer dereference a second or so after resume. It is completely locked up at this point; magic-sysreq gets no response. lspci shows that :00:1d.7 is # lspci -v -s :00:1d.7 00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: IBM: Unknown device 052e Flags: bus master, medium devsel, latency 0, IRQ 5 Memory at c000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port Complete lspci and .config attached. J 00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) Subsystem: IBM: Unknown device 0529 Flags: bus master, fast devsel, latency 0 Memory at d000 (32-bit, prefetchable) [size=256M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, fast devsel, latency 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: c010-c01f Prefetchable memory behind bridge: e000-e7ff 00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1800 [size=32] 00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 1820 [size=32] 00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1840 [size=32] 00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: IBM: Unknown device 052e Flags: bus master, medium devsel, latency 0, IRQ 5 Memory at c000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corp. 82801 Mobile PCI Bridge (rev 81) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=08, sec-latency=64 I/O behind bridge: 4000-8fff Memory behind bridge: c020-cfff Prefetchable memory behind bridge: e800-efff 00:1f.0 ISA bridge: Intel Corp. 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4-M) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at 1860 [size=16] Memory at 4000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) Subsystem: IBM: Unknown device 052d Flags: medium devsel, IRQ 10 I/O ports at 1880 [size=32] 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) Subsystem: IBM: Unknown device 0534 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 1c00 [size=256] I/O ports at 18c0 [size=64] Memory at cc00 (32-bit, non-prefetchable) [size=512] Memory at c800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) (prog-if 00 [Generic]) Subsystem: IBM: Unknown device 0524 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 2400 [size=256] I/O ports at 2000 [size=128] Capabilities: [50] Power Management version 2 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 052f Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 11 Memory at e000 (32-bit, prefetchable) [size=128M] I/O ports at 3000 [size=256] Memory at c010 (32-bit,
Re: [ACPI] Re: 2.6.12-rc1-mm3
On Fri, 2005-03-25 at 21:02, Jason Uhlenkott wrote: > On Fri, Mar 25, 2005 at 08:56:58PM -0500, Len Brown wrote: > > Please send me the .config you'd like to build. > > arch/ia64/configs/sn2_defconfig > > I believe that what we want to do is include CONFIG_PM. > > At first glance, it looks like that will enable suspend/resume > functionality (which I don't think we want on SGI sn2) for a bunch of > drivers. What bad things happen if you define CONFIG_PM on SN2? Re: CONFIG_ACPI_BOOT I've got a patch that makes it go away -- this looks like a good reason for me to dust it off... Looks like arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig, which it should not do - it should look like i386/Kconfig... -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/12] More Driver Model Locking Changes
On Fri, 25 Mar 2005, Greg KH wrote: > On Fri, Mar 25, 2005 at 03:39:52PM -0800, Greg KH wrote: > > But can you take a look at drivers/scsi/scsi_transport_spi.c, line 265? > > That is also going to need fixing up somehow. Gotta love that FIXME > > comment... Heh, funky. > Ok, the patch below seems to fix it, but I would like some validation I > did the correct thing. It looks Ok to me. > Oh, looks like pci express now has problems too, I'll go hit that one > next... Bah, sorry about that. What config are you using to test, 'allmodconfig'? Thanks, Pat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc1-mm3] Fix typo in scdrv_init()
Fix a typo in scdrv_init() which was breaking the build for SGI sn2. Signed-off-by: Jason Uhlenkott <[EMAIL PROTECTED]> Index: linux/drivers/char/snsc.c === --- linux.orig/drivers/char/snsc.c 2005-03-25 16:53:13.426753917 -0800 +++ linux/drivers/char/snsc.c 2005-03-25 16:53:21.456116301 -0800 @@ -437,7 +437,7 @@ continue; } - class__device_create(snsc_class, dev, NULL, + class_device_create(snsc_class, dev, NULL, "%s", devname); ia64_sn_irtr_intr_enable(scd->scd_nasid, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] freepgt: free_pgtables shakeup
Russell King wrote: On Wed, Mar 23, 2005 at 05:10:15PM +, Hugh Dickins wrote: Here's the recut of those patches, including David Miller's vital fixes. I'm addressing these to Nick rather than Andrew, because they're perhaps not fit for -mm until more testing done and the x86_64 32-bit vdso issue handled. I'm unlikely to be responsive until next week, sorry: over to you, Nick - thanks. I thought I'd try these out on ARM, but alas they don't apply to 2.6.12-rc1. ;( This means I won't be testing them, sorry. The reject should be confined to include/asm-ia64, so it will still work for you. But I've put a clean rollup of all Hugh's patches here in case you'd like to try it. http://www.kerneltrap.org/~npiggin/freepgt-2.6.12-rc1.patch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.12-rc1-mm3
On Fri, Mar 25, 2005 at 08:56:58PM -0500, Len Brown wrote: > Please send me the .config you'd like to build. arch/ia64/configs/sn2_defconfig > I believe that what we want to do is include CONFIG_PM. At first glance, it looks like that will enable suspend/resume functionality (which I don't think we want on SGI sn2) for a bunch of drivers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.12-rc1-mm3
On Fri, 2005-03-25 at 20:43, Jason Uhlenkott wrote: > On Fri, Mar 25, 2005 at 12:21:54AM -0800, Andrew Morton wrote: > > bk-acpi.patch > > This doesn't build for SGI sn2: > > arch/ia64/kernel/mca.c: In function `ia64_mca_init': > arch/ia64/kernel/mca.c:1394: error: `ACPI_INTERRUPT_CPEI' undeclared > (first use in this function) > arch/ia64/kernel/mca.c:1394: error: (Each undeclared identifier is > reported only once > arch/ia64/kernel/mca.c:1394: error: for each function it appears in.) > make[1]: *** [arch/ia64/kernel/mca.o] Error 1 > make: *** [arch/ia64/kernel] Error 2 > > This is because we lost CONFIG_ACPI_BOOT -- it now depends on > CONFIG_PM, which we don't have (or want) on sn2. The following fixes > it, but I'm not sure what the original rationale was. Len? > > Signed-off-by: Jason Uhlenkott <[EMAIL PROTECTED]> > Please send me the .config you'd like to build. I believe that what we want to do is include CONFIG_PM. Note also that CONFIG_ACPI_BOOT will be going away -- to be replaced simply by CONFIG_ACPI. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3
On Fri, Mar 25, 2005 at 12:21:54AM -0800, Andrew Morton wrote: > bk-acpi.patch This doesn't build for SGI sn2: arch/ia64/kernel/mca.c: In function `ia64_mca_init': arch/ia64/kernel/mca.c:1394: error: `ACPI_INTERRUPT_CPEI' undeclared (first use in this function) arch/ia64/kernel/mca.c:1394: error: (Each undeclared identifier is reported only once arch/ia64/kernel/mca.c:1394: error: for each function it appears in.) make[1]: *** [arch/ia64/kernel/mca.o] Error 1 make: *** [arch/ia64/kernel] Error 2 This is because we lost CONFIG_ACPI_BOOT -- it now depends on CONFIG_PM, which we don't have (or want) on sn2. The following fixes it, but I'm not sure what the original rationale was. Len? Signed-off-by: Jason Uhlenkott <[EMAIL PROTECTED]> Index: linux/drivers/acpi/Kconfig === --- linux.orig/drivers/acpi/Kconfig 2005-03-25 12:22:57.909667494 -0800 +++ linux/drivers/acpi/Kconfig 2005-03-25 16:28:35.793588269 -0800 @@ -3,7 +3,6 @@ # menu "ACPI (Advanced Configuration and Power Interface) Support" - depends on PM depends on !X86_VISWS depends on !IA64_HP_SIM depends on IA64 || X86 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][trivial] fix tiny spelling error in init/Kconfig
Fix spelling in init/Kconfig Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.12-rc1-mm3-orig/init/Kconfig 2005-03-25 15:29:08.0 +0100 +++ linux-2.6.12-rc1-mm3/init/Kconfig 2005-03-26 02:24:33.0 +0100 @@ -83,7 +83,7 @@ default y help This option allows you to choose whether you want to have support - for socalled swap devices or swap files in your kernel that are + for so called swap devices or swap files in your kernel that are used to provide more virtual memory than the actual RAM present in your computer. If unsure say Y. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] xfrm_policy destructor fix
David S. Miller <[EMAIL PROTECTED]> wrote:
> On Fri, 25 Mar 2005 15:34:41 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> the patch below fixes a bug that i encountered while running a
>> PREEMPT_RT kernel, but i believe it should be fixed in the generic
>> kernel too. xfrm_policy_kill() queues a destroyed policy structure to
>> the GC list, and unlocks the policy->lock spinlock _after_ that point.
>> This created a scenario where GC processing got to the new structure
>> first, and kfree()d it - then the write_unlock_bh() was done on the
>> already kfreed structure. There is no guarantee that GC processing will
>> be done after policy->lock has been dropped and softirq processing has
>> been enabled.
>
> Good catch Ingo, patch applied. Thanks.
Sorry, that was my fault. I dropped the GC code inside the locks
without thinking.
In fact, the GC list linking doesn't need to sit inside the locks
at all. The locks are there to guard the setting of policy->dead
only.
So here is a patch to simplify xfrm_policy_kill() by moving the
GC linking after the write_unlock_bh().
Actually, as the code stands, xfrm_policy_kill() should/will never
be called twice on the same policy. So we can add a warning to
catch that.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
= net/xfrm/xfrm_policy.c 1.74 vs edited =
--- 1.74/net/xfrm/xfrm_policy.c 2005-03-26 04:25:09 +11:00
+++ edited/net/xfrm/xfrm_policy.c 2005-03-26 12:07:08 +11:00
@@ -13,6 +13,7 @@
*
*/
+#include
#include
#include
#include
@@ -300,20 +301,20 @@
static void xfrm_policy_kill(struct xfrm_policy *policy)
{
+ int dead;
+
write_lock_bh(>lock);
- if (policy->dead) {
- write_unlock_bh(>lock);
+ dead = policy->dead;
+ policy->dead = 1;
+ write_unlock_bh(>lock);
+
+ if (unlikely(dead)) {
+ WARN_ON(1);
return;
}
- policy->dead = 1;
spin_lock(_policy_gc_lock);
list_add(>list, _policy_gc_list);
- /*
-* Unlock the policy (out of order unlocking), to make sure
-* the GC context does not free it with an active lock:
-*/
- write_unlock_bh(>lock);
spin_unlock(_policy_gc_lock);
schedule_work(_policy_gc_work);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Sat, 2005-03-26 at 01:38 +0100, Julien Wajsberg wrote: > On Fri, 25 Mar 2005 18:14:22 -0500, Lee Revell <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote: > > > - audio works too. The only problem is that two applications can't > > > open /dev/dsp in the same time. > > > > Not a problem. ALSA does software mixing for chipsets that can't do it > > in hardware. Google for dmix. > > > > However this doesn't (and can't be made to) work with the in-kernel OSS > > emulation (it works fine with the alsa-lib/libaoss emulation). So you > > are technically correct in that two OSS apps can't open /dev/dsp at the > > same time, but there is no problem with multiple apps sharing the sound > > device, as long as they use the ALSA API (which they should be using > > anyway). > > Okay, good to know. Then I'll have to find out why beep-media-player > doesn't work with alsa :-) > Without knowing anything about it, I'm willing to guess "programmer laziness/lack of time" (depending on your perspective). As long as ALSA continues to provide OSS emulation, lazy developers will not update their apps to the (superior) ALSA API. I just upgraded all my home machines to a Gnome 2.10 based distro and way shocked to find that it still uses esd via OSS emulation for system sounds. So the endless user complaints about "wtf, esd is blocking my sound device, on windows my apps can share it" will not be going away in the forseeable future. Ugh. dmix has only been available for, oh, 18 months, and the apps still have not caught up. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.12-rc1-bk1: Inconsistent kallsyms data
While building 2.6.12-rc1-bk1 with attached config I get "Inconsistent kallsyms data". Setting CONFIG_KALLSYMS_EXTRA_PASS or CONFIG_KALLSYMS_ALL fixes the problem. Noted differences: --- System.map +++ .tmp_System.map -c03cf83c D kallsyms_markers -c03cf8d4 D kallsyms_token_table -c03cfce4 D kallsyms_token_index +c03cf804 D kallsyms_markers +c03cf89c D kallsyms_token_table +c03cfcb0 D kallsyms_token_index Huge chunk of symbols in tmp_kallsyms2.S are shifted by 0x2 wrt tmp_kallsyms1.S (_sinittext and _einittext being among them). --- tmp_kallsyms1.S_ +++ tmp_kallsyms2.S_ -T __sched_text_start PTR 0xc0311e9e +T __sched_text_start PTR 0xc0311ea0 -T _sinittext PTR 0xc03b5000 +T _sinittext PTR 0xc03d5000 -T _einittext PTR 0xc03cc682 +T _einittext PTR 0xc03ec682 Gnu C 3.4.2 binutils 2.15.92.0.2 Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_KALLSYMS=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_KMOD=y CONFIG_X86_PC=y CONFIG_MPENTIUM4=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_BLACKLIST_YEAR=2001 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_NAMES=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_PNP=y CONFIG_PNPACPI=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_CFQ=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_SYN_COOKIES=y CONFIG_IP_TCPDIAG=m CONFIG_NETFILTER=y CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_MATCH_CONNMARK=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_CONNMARK=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_XFRM=y
Re: How's the nforce4 support in Linux?
On Fri, 25 Mar 2005 18:14:22 -0500, Lee Revell <[EMAIL PROTECTED]> wrote: > On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote: > > - audio works too. The only problem is that two applications can't > > open /dev/dsp in the same time. > > Not a problem. ALSA does software mixing for chipsets that can't do it > in hardware. Google for dmix. > > However this doesn't (and can't be made to) work with the in-kernel OSS > emulation (it works fine with the alsa-lib/libaoss emulation). So you > are technically correct in that two OSS apps can't open /dev/dsp at the > same time, but there is no problem with multiple apps sharing the sound > device, as long as they use the ALSA API (which they should be using > anyway). Okay, good to know. Then I'll have to find out why beep-media-player doesn't work with alsa :-) -- Julien - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
On Sat, Mar 26, 2005 at 03:47:33AM +0300, Evgeniy Polyakov wrote:
>
> It looks like we all misunderstand each other -
> why do you think that if there will be kernel <-> kernel
> RNG dataflow, then system will continuously spent all
> it's time to produce that data?
It doesn't matter whether it's like that or not.
The point is if you do it in the kernel then either you'll have very
coarse controls over the rate of data coming out of the hardware RNG,
e.g., only on/off, or you'll have to put more code in to set the rate
appropriately.
Either way it's a loss compared to doing it in user-space.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4] SGI 932676 link_path_walk refcount problem allows umount of active filesystem
On Tue, Mar 22, 2005 at 12:24:37PM +1100, Greg Banks wrote: > G'day, > > The attached patch fixes a bug in the VFS code which causes > "Busy inodes after unmount" and a subsequent oops. Applied, thanks. > > Greg. > -- > Greg Banks, R Software Engineer, SGI Australian Software Group. > I don't speak for SGI. > > Following an absolute symlink opens a window during which the > filesystem containing the symlink has an outstanding dentry count > and no outstanding vfsmount count. A umount() of the filesystem can > (incorrectly) proceed, resulting in the "Busy inodes after unmount" > message and an oops shortly thereafter. > > Systems using autofs-controlled NFS mounts are especially vulnerable, > as autofs both increases the number of unmounts happening and does NFS > mounting in response to lookups which can result in multiple-second > vulnerability windows. However the bug could happen on any filesystem. > > This patch adds a mntget()/mntput() pair around the link following code > (as the 2.6 code does). Attempts to umount() during link following > now return EBUSY. > > > Signed-off-by: Greg Banks <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] freepgt: free_pgtables use vma list
On Fri, 25 Mar 2005 09:23:12 -0800 "David S. Miller" <[EMAIL PROTECTED]> wrote: > On Fri, 25 Mar 2005 16:32:07 +1100 > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > So, to make the question more concrete: if a pgd_t is freed due > > to freeing the single pmd_t contained within it (which was the > > only part of the pgd's address space that contained a valid mapping) > > Then do you need the full PGDIR_SIZE width passed to > > flush_tlb_pgtables, or just the PMD_SIZE'd start,end that covered > > the freed pmd_t? > > Just the PMD_SIZE'd start,end is necessary. Since sparc64 is the only user of this thing... Let's make it so that the flush can be queued up at pmd_clear() time, as that's what we really want. Something like: pmd_clear(mm, vaddr, pmdp); I'll try to play with something like this later. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: OOM problems on 2.6.12-rc1 with many fsx tests
On Fri, 2005-03-25 at 16:17, Dave Jones wrote: > On Wed, Mar 23, 2005 at 11:53:04AM -0800, Mingming Cao wrote: > > > The fsx command is: > > > > ./fsx -c 10 -n -r 4096 -w 4096 /mnt/test/foo1 & > > > > I also see fsx tests start to generating report about read bad data > > about the tests have run for about 9 hours(one hour before of the OOM > > happen). > > Is writing to the same testfile from multiple fsx's supposed to work? > It sounds like a surefire way to break the consistency checking that it does. > I'm surprised it lasts 9hrs before it breaks. > > In the past I've done tests like.. > > for i in `seq 1 100` > do > fsx foo$i & > done > > to make each process use a different test file. > No. We are doing on different files - Mingming cut and pasted only a single line from the script. Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
On Sat, 26 Mar 2005 10:47:45 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 25, 2005 at 06:43:49PM -0500, Jeff Garzik wrote:
> >
> > In any case, it is the wrong solution to simply "turn on the tap" and
> > let the RNG spew data. There needs to be a limiting factor... typically
> > rngd should figure out when /dev/random needs more entropy, or simply
> > delay a little bit between entropy collection/stuffing runs.
>
> Completely agreed. Having it in rngd also allows the scheduler to
> do its job.
It looks like we all misunderstand each other -
why do you think that if there will be kernel <-> kernel
RNG dataflow, then system will continuously spent all
it's time to produce that data?
_Ability_ existence does not mean that only it must be used.
Userspace daemon should be able to turn it on or off,
but it is too expensive to allow it to be not only dataflow
controller, but the only random numbers dataflow initiator.
I can create following patch on top of rngd -
it will read from /dev/random, if read succeds too fast
(or even better just to check pool counts), then rngd
will turn HW RNG assist off and examine received data
to check if it is valid.
Later it can be turned on again.
> When applications need entropy from /dev/random and they can't get it,
> they'll simply block which allows rngd to run to refill the tank.
Such a blocking will be definitely a sign to turn
HW RNG assist on.
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Fri, 25 Mar 2005 18:20:54 -0500, Lee Revell <[EMAIL PROTECTED]> wrote: > On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote: > > I also experiment sometimes a complete hang of the system. But I > > didn't find how to reproduce the bug yet, especially because it seems > > to happen when I do nothing (when I'm sleeping or am at work ;), and I > > can't get a Oops because I don't have any serial console... > > You could try netconsole... Good point... I just tried, but forcedeth doesn't support netpoll. If you have a pointer, I could try to implement it ;-) -- Julien - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM problems on 2.6.12-rc1 with many fsx tests
On Wed, Mar 23, 2005 at 11:53:04AM -0800, Mingming Cao wrote: > The fsx command is: > > ./fsx -c 10 -n -r 4096 -w 4096 /mnt/test/foo1 & > > I also see fsx tests start to generating report about read bad data > about the tests have run for about 9 hours(one hour before of the OOM > happen). Is writing to the same testfile from multiple fsx's supposed to work? It sounds like a surefire way to break the consistency checking that it does. I'm surprised it lasts 9hrs before it breaks. In the past I've done tests like.. for i in `seq 1 100` do fsx foo$i & done to make each process use a different test file. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature Request Into Kernel - Savage DRM to be added as a selectable DRM module in the kernel
> I was hopeing that it could be added as a selectable DRM module in the > kernel such as the ati rage and such are. This is a tested driver, > proven working for most, making it selectable in the kernel would be > very much appreciated and a great advancment for all savage users. The > savage users have for long been without opengl, now the time comes > when it can happen, i was sincerley hoping that this could be added > into the kernel. i was hoping it will become part in the list of > selectable DRM in the gentoo kernel, vanilla, etc.. whatever it is > easier to include it in. I would appericate a responce on your > thoughts, and im here for testing if needed. > Its on my list of things.. just not as high up as some other things.. it needs a full code review by a few people which means a lot of time, it may also need to be cleaned up to kernel coding standards I might submit a patch for review soon... Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/12] More Driver Model Locking Changes
On Fri, Mar 25, 2005 at 03:39:52PM -0800, Greg KH wrote:
> But can you take a look at drivers/scsi/scsi_transport_spi.c, line 265?
> That is also going to need fixing up somehow. Gotta love that FIXME
> comment...
Ok, the patch below seems to fix it, but I would like some validation I
did the correct thing.
Oh, looks like pci express now has problems too, I'll go hit that one
next...
thanks,
greg k-h
-
[scsi] use device_for_each_child() to properly access child devices.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
diff -Nru a/drivers/scsi/scsi_transport_spi.c
b/drivers/scsi/scsi_transport_spi.c
--- a/drivers/scsi/scsi_transport_spi.c 2005-03-25 16:03:09 -08:00
+++ b/drivers/scsi/scsi_transport_spi.c 2005-03-25 16:03:09 -08:00
@@ -254,17 +254,21 @@
spi_transport_rd_attr(rti, "%d\n");
spi_transport_rd_attr(pcomp_en, "%d\n");
+/* we only care about the first child device so we return 1 */
+static int child_iter(struct device *dev, void *data)
+{
+ struct scsi_device *sdev = to_scsi_device(dev);
+
+ spi_dv_device(sdev);
+ return 1;
+}
+
static ssize_t
store_spi_revalidate(struct class_device *cdev, const char *buf, size_t count)
{
struct scsi_target *starget = transport_class_to_starget(cdev);
- /* FIXME: we're relying on an awful lot of device internals
-* here. We really need a function to get the first available
-* child */
- struct device *dev = container_of(starget->dev.children.next, struct
device, node);
- struct scsi_device *sdev = to_scsi_device(dev);
- spi_dv_device(sdev);
+ device_for_each_child(>dev, NULL, child_iter);
return count;
}
static CLASS_DEVICE_ATTR(revalidate, S_IWUSR, NULL, store_spi_revalidate);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
On Fri, Mar 25, 2005 at 06:43:49PM -0500, Jeff Garzik wrote:
>
> In any case, it is the wrong solution to simply "turn on the tap" and
> let the RNG spew data. There needs to be a limiting factor... typically
> rngd should figure out when /dev/random needs more entropy, or simply
> delay a little bit between entropy collection/stuffing runs.
Completely agreed. Having it in rngd also allows the scheduler to
do its job.
When applications need entropy from /dev/random and they can't get it,
they'll simply block which allows rngd to run to refill the tank.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
On Fri, Mar 25, 2005 at 04:50:16PM -0600, Kim Phillips wrote: > I did some tests and found that the udelay(200) call in hw_random.c is > not good for extreme RNG consumption. Whether or not such extremes > occur in real life, on the mpc8541, /dev/hwrandom is an order of > magnitude slower than /dev/random, and two orders of magnitude slower > than /dev/urandom. The hardware RNG is capable of exceeding software > /dev/random speeds plus it would alleviate the core to do other, more > useful things (that's being realistic). Consider what an RNG does: spews garbage. In practical applications, you -do not- want to dedicate the machine to spewing garbage. The vast majority of users would prefer to use their machines for real stuff. Thus, "extreme RNG consumption" is largely irrelevant to sane usage. That said, I cannot remember if the udelay() is hardcoding a policy decision (bad), or required for the hardware. In any case, it is the wrong solution to simply "turn on the tap" and let the RNG spew data. There needs to be a limiting factor... typically rngd should figure out when /dev/random needs more entropy, or simply delay a little bit between entropy collection/stuffing runs. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Fri, 25 Mar 2005 18:21:42 -0500, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> > Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> > Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> > Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> > DriveReady SeekComplete DataRequest }
> > Mar 25 22:42:55 evenflow kernel:
> > Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> > Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> > Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> > Mar 25 22:42:55 evenflow kernel:
> > Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> > Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> > Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
>
> Are you sure the drive is OK? Those messages are the classic signs of a
> failing drive...
It's nearly new, and it was ok in my last computer (an old P3-500 with
PIIX4, IIRC).
BTW I did a complete badblocks check on it, and it found nothing.
--
Julien
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [0/12] More Driver Model Locking Changes
On Fri, Mar 25, 2005 at 11:20:24AM -0800, Greg KH wrote:
> On Thu, Mar 24, 2005 at 09:54:24PM -0800, Patrick Mochel wrote:
> >
> > Here is the next round of driver model locking changes. These build off of
> > the previous set of changes, including the klist patch. They eradicate all
> > of the uses of the subsystems' rwsem in the driver core.
> >
> > It does include the fix posted earlier that happened when removing the
> > driver.
> >
> > A summary is listed below. The patches follow.
>
> Looks great, I've pulled all of these into my tree.
>
> thanks a lot for doing this work.
Oops, I needed a fix for the ieee1394 code (attached and applied to my
trees.
But can you take a look at drivers/scsi/scsi_transport_spi.c, line 265?
That is also going to need fixing up somehow. Gotta love that FIXME
comment...
thanks,
greg k-h
Subject: [ieee1394] Use device_for_each_child() to unregister devices in
nodemgr_remove_host_dev()
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
diff -Nru a/drivers/ieee1394/nodemgr.c b/drivers/ieee1394/nodemgr.c
--- a/drivers/ieee1394/nodemgr.c2005-03-25 12:04:35 -08:00
+++ b/drivers/ieee1394/nodemgr.c2005-03-25 12:04:35 -08:00
@@ -695,14 +695,15 @@
put_device(dev);
}
+static int __nodemgr_remove_host_dev(struct device *dev, void *data)
+{
+ nodemgr_remove_ne(container_of(dev, struct node_entry, device));
+ return 0;
+}
static void nodemgr_remove_host_dev(struct device *dev)
{
- struct device *ne_dev, *next;
-
- list_for_each_entry_safe(ne_dev, next, >children, node)
- nodemgr_remove_ne(container_of(ne_dev, struct node_entry,
device));
-
+ device_for_each_child(dev, NULL, __nodemgr_remove_host_dev);
sysfs_remove_link(>kobj, "irm_id");
sysfs_remove_link(>kobj, "busmgr_id");
sysfs_remove_link(>kobj, "host_id");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> DriveReady SeekComplete DataRequest }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Are you sure the drive is OK? Those messages are the classic signs of a
failing drive...
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote: > I also experiment sometimes a complete hang of the system. But I > didn't find how to reproduce the bug yet, especially because it seems > to happen when I do nothing (when I'm sleeping or am at work ;), and I > can't get a Oops because I don't have any serial console... You could try netconsole... Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH libata-dev-2.6] libata: flush COMRESET write
Jeff,
I'm seeing single drives getting stuck in ata_busy_sleep() with these
log messages on boot:
<4>ata2 is slow to respond, please be patient
<3>ata2 failed to respond (30 secs)
One thing I found was the bug fixed below, where the COMRESET wasn't
getting flushed properly. This may or may not be the reason, but it
can't hurt. I have to keep looking and testing.
I wanted to also send a separate patch to ensure the port was stopped
before issuing COMRESET, since this is required by at least the ICH6R,
but the port_stop() routines seemed too heavy to call from
__sata_phy_reset() so I'm not sending anything like that yet.
Signed-off-by: Brett Russ <[EMAIL PROTECTED]>
Index: libata-dev-2.6/drivers/scsi/libata-core.c
===
--- libata-dev-2.6.orig/drivers/scsi/libata-core.c 2005-03-23
16:44:48.0 -0500
+++ libata-dev-2.6/drivers/scsi/libata-core.c 2005-03-25 16:58:22.0
-0500
@@ -1262,7 +1262,7 @@
if (ap->flags & ATA_FLAG_SATA_RESET) {
scr_write(ap, SCR_CONTROL, 0x301); /* issue phy wake/reset */
- scr_read(ap, SCR_STATUS); /* dummy read; flush */
+ scr_read(ap, SCR_CONTROL); /* dummy read; flush */
udelay(400);/* FIXME: a guess */
}
scr_write(ap, SCR_CONTROL, 0x300); /* issue phy wake/clear reset */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote: > - audio works too. The only problem is that two applications can't > open /dev/dsp in the same time. Not a problem. ALSA does software mixing for chipsets that can't do it in hardware. Google for dmix. However this doesn't (and can't be made to) work with the in-kernel OSS emulation (it works fine with the alsa-lib/libaoss emulation). So you are technically correct in that two OSS apps can't open /dev/dsp at the same time, but there is no problem with multiple apps sharing the sound device, as long as they use the ALSA API (which they should be using anyway). Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove redundant NULL pointer checks prior to calling kfree() in fs/nfsd/
On Fri, 25 Mar 2005, linux-os wrote: > On Fri, 25 Mar 2005, Jesper Juhl wrote: > > > (please keep me on CC) > > > > > > checking for NULL before calling kfree() is redundant and needlessly > > enlarges the kernel image, let's get rid of those checks. > > > > Hardly. ORing a value with itself and jumping on condition is > real cheap compared with pushing a value into the stack and > calling a function. This is NOT a good change if you want > performance. You really should reconsider this activity. It > is quite counter-productive. > > Let's have a look - at fs/nfsd/export.o for example. Size first. Without my patch : $ ls -l fs/nfsd/export.o -rw-r--r-- 1 juhl users 97144 2005-03-25 23:58 fs/nfsd/export.o With my patch : $ ls -l fs/nfsd/export.o -rw-r--r-- 1 juhl users 97092 2005-03-25 23:59 fs/nfsd/export.o That's our first bennefit - 52 bytes saved - not much, but still some. Now let's take a look at the code gcc generates for one of the functions - expkey_parse for example. Here's a diff -u of an objdump -D of export.o cut down to just the bit for expkey_parse : --- func-without-patch 2005-03-26 00:02:47.0 +0100 +++ func-with-patch 2005-03-26 00:03:26.0 +0100 @@ -8,7 +8,7 @@ 13b: 81 ec d0 00 00 00 sub$0xd0,%esp 141: 89 95 40 ff ff ff mov%edx,0xff40(%ebp) 147: 80 7c 0a ff 0a cmpb $0xa,0x(%edx,%ecx,1) - 14c: 0f 85 2b 02 00 00 jne37d + 14c: 0f 85 27 02 00 00 jne379 152: c6 44 0a ff 00 movb $0x0,0x(%edx,%ecx,1) 157: a1 64 00 00 00 mov0x64,%eax 15c: ba d0 00 00 00 mov$0xd0,%edx @@ -17,7 +17,7 @@ 168: 89 c3 mov%eax,%ebx 16a: c7 85 30 ff ff ff f4movl $0xfff4,0xff30(%ebp) 171: ff ff ff - 174: 0f 84 fd 01 00 00 je 377 + 174: 0f 84 f2 01 00 00 je 36c 17a: 89 c2 mov%eax,%edx 17c: 8d 85 40 ff ff ff lea0xff40(%ebp),%eax 182: b9 00 10 00 00 mov$0x1000,%ecx @@ -52,7 +52,7 @@ 208: 80 38 00cmpb $0x0,(%eax) 20b: 0f 85 46 01 00 00 jne357 211: f6 05 00 00 00 00 04testb $0x4,0x0 - 218: 0f 85 6a 01 00 00 jne388 + 218: 0f 85 66 01 00 00 jne384 21e: 83 ff 02cmp$0x2,%edi 221: 0f 8f 30 01 00 00 jg 357 227: 8d 85 40 ff ff ff lea0xff40(%ebp),%eax @@ -134,22 +134,20 @@ 35f: 74 0b je 36c 361: 8b 85 34 ff ff ff mov0xff34(%ebp),%eax 367: e8 fc ff ff ff call 368 - 36c: 85 db test %ebx,%ebx - 36e: 74 07 je 377 - 370: 89 d8 mov%ebx,%eax - 372: e8 fc ff ff ff call 373 - 377: 8b 85 30 ff ff ff mov0xff30(%ebp),%eax - 37d: 81 c4 d0 00 00 00 add$0xd0,%esp - 383: 5b pop%ebx - 384: 5e pop%esi - 385: 5f pop%edi - 386: c9 leave - 387: c3 ret - 388: 89 7c 24 04 mov%edi,0x4(%esp) - 38c: c7 04 24 03 00 00 00movl $0x3,(%esp) - 393: e8 fc ff ff ff call 394 - 398: e9 81 fe ff ff jmp21e - 39d: 8d 76 00lea0x0(%esi),%esi + 36c: 89 d8 mov%ebx,%eax + 36e: e8 fc ff ff ff call 36f + 373: 8b 85 30 ff ff ff mov0xff30(%ebp),%eax + 379: 81 c4 d0 00 00 00 add$0xd0,%esp + 37f: 5b pop%ebx + 380: 5e pop%esi + 381: 5f pop%edi + 382: c9 leave + 383: c3 ret + 384: 89 7c 24 04 mov%edi,0x4(%esp) + 388: c7 04 24 03 00 00 00movl $0x3,(%esp) + 38f: e8 fc ff ff ff call 390 + 394: e9 85 fe ff ff jmp21e + 399: 8d b4 26 00 00 00 00lea0x0(%esi),%esi 3a0: 89 5c 24 04 mov%ebx,0x4(%esp) 3a4: c7 04 24 16 00 00 00movl $0x16,(%esp) 3ab: e8 fc ff ff ff call 3ac This is not too bad, but I've seen a lot worse, see this one for a gross example : http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/1050.html -- Jesper Juhl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More
Re: How's the nforce4 support in Linux?
Hi
Just to answer some questions :
- USB works ok since 2.6.11
- audio works too. The only problem is that two applications can't
open /dev/dsp in the same time.
- network works
I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
experiment the following problem :
Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Of course, if I disable DMA with hdparm, this problem disappear.. but
it isn't a long-term solution ;-)
Using vanilla 2.6.11.5 kernel. I attached the config file.
I also experiment sometimes a complete hang of the system. But I
didn't find how to reproduce the bug yet, especially because it seems
to happen when I do nothing (when I'm sleeping or am at work ;), and I
can't get a Oops because I don't have any serial console...
Kind regards,
--
Julien Wajsberg
config-2.6.11.5
Description: Binary data
Re: 2.6.12-rc1 breaks dosemu
On Freedag 25 März 2005 20:14, Arjan van de Ven wrote: > the randomisation patches came in a series of 8 patches (where several > were general infrastructure); could you try to disable the individual > randomisations one at a time to see which one causes this effect? It's caused by top-of-stack-randomization.patch. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
"Jason Munro" <[EMAIL PROTECTED]> wrote: > > This fixes it here. > Steven Cole <[EMAIL PROTECTED]> wrote: > > The patch fixed it for me. Wheee. > OK, thanks guys. You're the best. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove redundant NULL pointer checks prior to calling kfree() in fs/nfsd/
On Fri, 25 Mar 2005, Jesper Juhl wrote:
(please keep me on CC)
checking for NULL before calling kfree() is redundant and needlessly
enlarges the kernel image, let's get rid of those checks.
Hardly. ORing a value with itself and jumping on condition is
real cheap compared with pushing a value into the stack and
calling a function. This is NOT a good change if you want
performance. You really should reconsider this activity. It
is quite counter-productive.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/nfsd/export.c 2005-03-21 23:12:41.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/nfsd/export.c 2005-03-25 22:48:11.0
+0100
@@ -189,8 +189,7 @@ static int expkey_parse(struct cache_det
out:
if (dom)
auth_domain_put(dom);
- if (buf)
- kfree(buf);
+ kfree(buf);
return err;
}
@@ -426,8 +425,7 @@ static int svc_export_parse(struct cache
path_release();
if (dom)
auth_domain_put(dom);
- if (buf)
- kfree(buf);
+ kfree(buf);
return err;
}
--- linux-2.6.12-rc1-mm3-orig/fs/nfsd/nfs4xdr.c 2005-03-25 15:28:59.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/nfsd/nfs4xdr.c 2005-03-25 22:49:53.0
+0100
@@ -151,8 +151,7 @@ u32 *read_buf(struct nfsd4_compoundargs
if (nbytes <= sizeof(argp->tmp))
p = argp->tmp;
else {
- if (argp->tmpp)
- kfree(argp->tmpp);
+ kfree(argp->tmpp);
p = argp->tmpp = kmalloc(nbytes, GFP_KERNEL);
if (!p)
return NULL;
@@ -2474,10 +2473,8 @@ void nfsd4_release_compoundargs(struct n
kfree(args->ops);
args->ops = args->iops;
}
- if (args->tmpp) {
- kfree(args->tmpp);
- args->tmpp = NULL;
- }
+ kfree(args->tmpp);
+ args->tmpp = NULL;
while (args->to_free) {
struct tmpbuf *tb = args->to_free;
args->to_free = tb->next;
--- linux-2.6.12-rc1-mm3-orig/fs/nfsd/nfscache.c2005-03-21
23:12:41.0 +0100
+++ linux-2.6.12-rc1-mm3/fs/nfsd/nfscache.c 2005-03-25 22:50:14.0
+0100
@@ -93,8 +93,7 @@ nfsd_cache_shutdown(void)
cache_disabled = 1;
- if (hash_list)
- kfree (hash_list);
+ kfree(hash_list);
hash_list = NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
On 4:23:36 pm 03/25/05 Andrew Morton <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > It's the new rock-ridge bounds checking.
>
> Try this, please?
>
> diff -puN fs/isofs/rock.c~rock-handle-directory-overflows-fix
> fs/isofs/rock.c --- 25/fs/isofs/rock.c~rock-handle-directory-overflows
> -fixFri Mar 25 14:21:32 2005
> +++ 25-akpm/fs/isofs/rock.cFri Mar 25 14:22:01 2005
> @@ -218,12 +218,12 @@ repeat:
> if (rr->len < 3)
> goto out;/* Something got screwed up here */
> sig = isonum_721(rs.chr);
> +if (rock_check_overflow(, sig))
> +goto eio;
> rs.chr += rr->len;
> rs.len -= rr->len;
> if (rs.len < 0)
> goto eio;/* corrupted isofs */
> -if (rock_check_overflow(, sig))
> -goto eio;
>
> switch (sig) {
> case SIG('R', 'R'):
> @@ -316,12 +316,12 @@ repeat:
> if (rr->len < 3)
> goto out;/* Something got screwed up here */
> sig = isonum_721(rs.chr);
> +if (rock_check_overflow(, sig))
> +goto eio;
> rs.chr += rr->len;
> rs.len -= rr->len;
> if (rs.len < 0)
> goto eio;/* corrupted isofs */
> -if (rock_check_overflow(, sig))
> -goto eio;
>
> switch (sig) {
> #ifndef CONFIG_ZISOFS/* No flag for SF or ZF */
> @@ -694,12 +694,12 @@ repeat:
> if (rr->len < 3)
> goto out;/* Something got screwed up here */
> sig = isonum_721(rs.chr);
> +if (rock_check_overflow(, sig))
> +goto out;
> rs.chr += rr->len;
> rs.len -= rr->len;
> if (rs.len < 0)
> goto out;/* corrupted isofs */
> -if (rock_check_overflow(, sig))
> -goto out;
>
> switch (sig) {
> case SIG('R', 'R'):
> _
This fixes it here.
\__ Jason Munro
\__ [EMAIL PROTECTED]
\__ http://hastymail.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH scsi-misc-2.6 08/08] scsi: fix hot unplug sequence
On Sat, 2005-03-26 at 06:43 +0900, Tejun Heo wrote: > 1. Allocate scsi_request and request (two are linked) This can't be done because the scsi_cmnd's are allocated specially (slab with reserve pool). James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] fork_connector: add a fork connector
On Fri, 25 Mar 2005, Guillaume Thouvenin wrote:
...
> The lmbench shows that the overhead (the construction and the sending
> of the message) in the fork() routine is around 7%.
...
> + /*
> + * size of data is the number of characters
> + * printed plus one for the trailing '\0'
> + */
> + memset(msg->data, '\0', CN_FORK_INFO_SIZE);
> + msg->len = scnprintf(msg->data, CN_FORK_INFO_SIZE-1,
> + "%i %i %i",
> + smp_processor_id(), parent, child) + 1;
i'm certain that if you used a struct {} and filled in 3 fields rather
than zeroing 64 bytes of memory, and doing 3 conversions to decimal ascii
then you'd see a marked decrease in the overhead of this. it's not clear
to me why you need ascii here -- the rest of the existing bsd accounting
code is not ascii (i'm assuming the purpose of the fork connector is for
accounting).
-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
Andrew Morton wrote: Andrew Morton <[EMAIL PROTECTED]> wrote: It's the new rock-ridge bounds checking. Try this, please? OK, you caught me just as I was headed out the door. ;) The patch fixed it for me. Wheee. [EMAIL PROTECTED] steven]# uname -r 2.6.12-rc1-mm3-GX110 [EMAIL PROTECTED] steven]# mount /dev/hdc /mnt/cdrom mount: block device /dev/hdc is write-protected, mounting read-only [EMAIL PROTECTED] steven]# df -T FilesystemTypeSize Used Avail Use% Mounted on /dev/hda1 ext3304M 96M 193M 34% / /dev/hda9 reiserfs8.3G 7.9G 335M 97% /home /dev/hda8 ext3464M 8.1M 432M 2% /tmp /dev/hda6 ext37.4G 1.5G 5.5G 22% /usr /dev/hda7 ext31.9G 97M 1.7G 6% /var /dev/hdc iso96602.9M 2.9M 0 100% /mnt/cdrom [EMAIL PROTECTED] steven]# ls -l /mnt/cdrom total 2578 -rw-rw-rw- 1 501 501 2639360 Aug 7 2003 snmp-opc server 30.msi [EMAIL PROTECTED] steven]# dmesg | tail [ 49.932278] EXT3 FS on hda8, internal journal [ 49.932292] EXT3-fs: mounted filesystem with ordered data mode. [ 49.966250] kjournald starting. Commit interval 5 seconds [ 49.966659] EXT3 FS on hda6, internal journal [ 49.99] EXT3-fs: mounted filesystem with ordered data mode. [ 49.994929] kjournald starting. Commit interval 5 seconds [ 49.995334] EXT3 FS on hda7, internal journal [ 49.995345] EXT3-fs: mounted filesystem with ordered data mode. [ 57.117794] PCI: Found IRQ 5 for device :01:0c.0 [ 123.944869] ISO 9660 Extensions: IEEE_P1282 Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no need to check for NULL before calling kfree() - fs/ext2/
On Fri, 25 Mar 2005, linux-os wrote: > > Isn't it expensive of CPU time to call kfree() even though the > pointer may have already been freed? I suggest that the check > for a NULL before the call is much less expensive than calling > kfree() and doing the check there. The resulting "double check" > is cheap, compared to the call. > I've been looking at some of the actual code gcc generates for those checks, and it's quite bloated. My guess is that the reduced memory footprint, one less branch, and the fact that kfree is probably already in cache (since it's called often all over the place) outweighs the cost of a function call - especially in the cases where the pointer is rarely NULL and we'll end up doing the call in any case. And the reduced use of screen real-estate is nice as well :) -- Jesper juhl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-10
On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote: > i have released the -V0.7.41-10 Real-Time Preemption patch, which can be > downloaded from the usual place: > >http://redhat.com/~mingo/realtime-preempt/ I get zillions of "return type defaults to int" warnings trying to compile this with PREEMPT_DESKTOP. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-10
* Lee Revell <[EMAIL PROTECTED]> wrote: > On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote: > > i have released the -V0.7.41-10 Real-Time Preemption patch, which can be > > downloaded from the usual place: > > > >http://redhat.com/~mingo/realtime-preempt/ > > I get zillions of "return type defaults to int" warnings trying to > compile this with PREEMPT_DESKTOP. i've uploaded -41-11 which should fix it. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32/64: Map prefetchable PCI without guarded bit
On Thu, 2005-03-24 at 19:20 +0100, Segher Boessenkool wrote: > > While experimenting with framebuffer access performances, we noticed a > > very significant improvement in write access to it when not setting > > the "guarded" bit on the MMU mappings. This bit basically says that > > reads and writes won't have side effects (it allows speculation). > > Unless the data is already in cache. > > > It appears that it also disables write combining. > > When the page is also cache-inhibited, it indeed does. > > > Btw, did you ever get to fix the problem with mapping the last page > of physical address space via /dev/mem ? I don't think so, but I'll have to double check. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
Andrew Morton wrote: Steven Cole <[EMAIL PROTECTED]> wrote: I found a few more minutes to test two more kernels. The problem first occured with 2.6.12-rc1-mm2: 2.6.12-rc1 reads the cd-rom OK as reported earlier 2.6.12-rc1-mm1 also reads the cd-rom OK 2.6.12-rc1-mm2 broken same as -mm3 described as above 2.6.12-rc1-mm3 broken as reported earlier Are you really really sure about that? -mm3 included both the bk-ide-dev tree and the isofs changes. 2.6.12-rc1-mm2 had neither. Just to be really really sure, I repeated the tests. I even checked that the image/label combination in /etc/lilo.conf was what I intended, but the uname -r should show what's what. Same results, -mm2 broken, and -mm1 reads the disk. I even tried other CD's just to make sure I didn't have something weird. Same results. OK, thanks. It would be interesting to copy a CD to hard disk (under -mm1) and see if it works OK with the loopback driver. Also, boot into -mm2 and do a `cmp' of the cdrom with the image which is on hard-disk. This should help us work out whether it's isofs, the driver, the VFS or whatever. - It seems that I've run out of time here today. If this is still an issue after the weekend, I'll do the above tests. Until then, Happy Easter. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32/64: Map prefetchable PCI without guarded bit
On Thu, 2005-03-24 at 08:54 -0800, Jesse Barnes wrote: > On Wednesday, March 23, 2005 10:24 pm, Benjamin Herrenschmidt wrote: > > While experimenting with framebuffer access performances, we noticed a > > very significant improvement in write access to it when not setting > > the "guarded" bit on the MMU mappings. This bit basically says that > > reads and writes won't have side effects (it allows speculation). It > > appears that it also disables write combining. > > Doesn't pgprot_writecombine imply non-guarded, so can't you use it instead? > Either way, you'll probably want to fix fbmem.c as well and turn off > _PAGE_GUARDED? I'm not sure we implement pgprot_writecombine. But anyway, that wouldn't help as X uses /dev/mem which doesn't use that, and sysfs new mmap interface doesn't have anything for setting writecombine. The interface I propose could be made generic, that is the whole point. It's basically a mean for the arch to say "heh, somebody wants to map this bit of physical address space, what pgprot should I use" :) The decision of wether to do uncacheable or writecombine, all the page_in_ram() trickery in /dev/mem or fbmem can be moved to arch specific routines and cleanup the generic stuff. > Maybe it's time for a more generic call to support this stuff, both for > in-kernel mappings and ones that we export to userspace. Yah, in-kernel mappings aren't covered yet, as my interface supposes a "struct file" but then, I don't use the struct file argument in my ppc implementation (I exposed it for the sake of archs that may want it). We could just define that in-kernel mappings can call this with NULL for struct file. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no need to check for NULL before calling kfree() - fs/ext2/
Isn't it expensive of CPU time to call kfree() even though the
pointer may have already been freed? I suggest that the check
for a NULL before the call is much less expensive than calling
kfree() and doing the check there. The resulting "double check"
is cheap, compared to the call.
On Fri, 25 Mar 2005, Jesper Juhl wrote:
(please keep me on CC)
kfree() handles NULL fine, to check is redundant.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/ext2/acl.c 2005-03-02 08:38:18.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ext2/acl.c 2005-03-25 22:41:07.0 +0100
@@ -194,8 +194,7 @@ ext2_get_acl(struct inode *inode, int ty
acl = NULL;
else
acl = ERR_PTR(retval);
- if (value)
- kfree(value);
+ kfree(value);
if (!IS_ERR(acl)) {
switch(type) {
@@ -262,8 +261,7 @@ ext2_set_acl(struct inode *inode, int ty
error = ext2_xattr_set(inode, name_index, "", value, size, 0);
- if (value)
- kfree(value);
+ kfree(value);
if (!error) {
switch(type) {
case ACL_TYPE_ACCESS:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
* Andrew Morton ([EMAIL PROTECTED]) wrote: > > (Please dont' edit the cc line. Just do reply-to-all) > > "Jason Munro" <[EMAIL PROTECTED]> wrote: > > > > > [ 146.301026] rock: directory entry would overflow storage > > > [ 146.301044] rock: sig=0x5245, size=8, remaining=0 > > > [ 158.388397] rock: directory entry would overflow storage > > > [ 158.388415] rock: sig=0x5850, size=36, remaining=34 > > > [EMAIL PROTECTED] steven]# > > > > > > Same results with mm3 here, though mm2 will not boot on my machine so I'm > > not sure about that. 2.6.12-rc1 works fine, rc1-mm3 successfully mounts the > > cdrom device but shows no contents. Releveant dmsesg output: > > > > rock: directory entry would overflow storage > > rock: sig=0x4543, size=28, remaining=0 > > rock: directory entry would overflow storage > > Seems that I am unable to read. It's the new rock-ridge bounds checking. > > It worked for me. Is someone able to get an image of a failing filesystem > into my hands? I'm interested as well. It should only be the last in the series. Does reverting it allow the CD to work? (I'm trying to make sure the other overflow check in the series isn't breaking things, I doubt is, but...). ftp.kernel.org:/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/broken-out/rock-handle-directory-overflows.patch thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
On 4:27:49 pm 03/25/05 "Jason Munro" <[EMAIL PROTECTED]> wrote: > On 4:06:54 pm 03/25/05 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > (Please dont' edit the cc line. Just do reply-to-all) > > Oops, reply-to-all it is. > > > "Jason Munro" <[EMAIL PROTECTED]> wrote: > > > > > > > [ 146.301026] rock: directory entry would overflow storage > > > > [ 146.301044] rock: sig=0x5245, size=8, remaining=0 > > > > [ 158.388397] rock: directory entry would overflow storage > > > > [ 158.388415] rock: sig=0x5850, size=36, remaining=34 > > > > [EMAIL PROTECTED] steven]# > > > > > > > > > Same results with mm3 here, though mm2 will not boot on my > > > machine so I'm not sure about that. 2.6.12-rc1 works fine, > > > rc1-mm3 successfully mounts the cdrom device but shows no > > > contents. Releveant dmsesg output: > > > rock: directory entry would overflow storage > > > rock: sig=0x4543, size=28, remaining=0 > > > rock: directory entry would overflow storage > > > > Seems that I am unable to read. It's the new rock-ridge bounds > > checking. > > > > It worked for me. Is someone able to get an image of a failing > > filesystem into my hands? > > I can reproduce it with the following: > > mkdir temp > touch temp/file1 temp/file2 temp/file3 > mkisofs -R -l temp > test.iso > mount -o loop /mnt/loop Of course that should be: mount -o loop test.iso /mnt/loop :) \__ Jason Munro \__ [EMAIL PROTECTED] \__ http://hastymail.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
On 4:06:54 pm 03/25/05 Andrew Morton <[EMAIL PROTECTED]> wrote: > > (Please dont' edit the cc line. Just do reply-to-all) Oops, reply-to-all it is. > "Jason Munro" <[EMAIL PROTECTED]> wrote: > > > > > [ 146.301026] rock: directory entry would overflow storage > > > [ 146.301044] rock: sig=0x5245, size=8, remaining=0 > > > [ 158.388397] rock: directory entry would overflow storage > > > [ 158.388415] rock: sig=0x5850, size=36, remaining=34 > > > [EMAIL PROTECTED] steven]# > > > > > > Same results with mm3 here, though mm2 will not boot on my machine > > so I'm not sure about that. 2.6.12-rc1 works fine, rc1-mm3 > > successfully mounts the cdrom device but shows no contents. > > Releveant dmsesg output: > > rock: directory entry would overflow storage > > rock: sig=0x4543, size=28, remaining=0 > > rock: directory entry would overflow storage > > Seems that I am unable to read. It's the new rock-ridge bounds > checking. > > It worked for me. Is someone able to get an image of a failing > filesystem into my hands? I can reproduce it with the following: mkdir temp touch temp/file1 temp/file2 temp/file3 mkisofs -R -l temp > test.iso mount -o loop /mnt/loop \__ Jason Munro \__ [EMAIL PROTECTED] \__ http://hastymail.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] don't check for NULL before calling kfree() in fs/ntfs/
(please keep me on CC)
There's no need to check a pointer for NULL before calling kfree() on it -
kfree() handles NULL pointers just fine on its own.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/ntfs/dir.c 2005-03-25 15:28:59.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ntfs/dir.c 2005-03-25 22:51:46.0 +0100
@@ -183,8 +183,7 @@ found_it:
name->len = 0;
*res = name;
} else {
- if (name)
- kfree(name);
+ kfree(name);
*res = NULL;
}
mref = le64_to_cpu(ie->data.dir.indexed_file);
@@ -444,8 +443,7 @@ found_it2:
name->len = 0;
*res = name;
} else {
- if (name)
- kfree(name);
+ kfree(name);
*res = NULL;
}
mref = le64_to_cpu(ie->data.dir.indexed_file);
@@ -1462,10 +1460,8 @@ err_out:
unlock_page(ia_page);
ntfs_unmap_page(ia_page);
}
- if (ir)
- kfree(ir);
- if (name)
- kfree(name);
+ kfree(ir);
+ kfree(name);
if (ctx)
ntfs_attr_put_search_ctx(ctx);
if (m)
--- linux-2.6.12-rc1-mm3-orig/fs/ntfs/namei.c 2005-03-25 15:28:59.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ntfs/namei.c2005-03-25 22:52:36.0
+0100
@@ -153,8 +153,7 @@ static struct dentry *ntfs_lookup(struct
ntfs_error(vol->sb, "ntfs_iget(0x%lx) failed with "
"error code %li.", dent_ino,
PTR_ERR(dent_inode));
- if (name)
- kfree(name);
+ kfree(name);
/* Return the error code. */
return (struct dentry *)dent_inode;
}
--- linux-2.6.12-rc1-mm3-orig/fs/ntfs/super.c 2005-03-25 15:28:59.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ntfs/super.c2005-03-25 22:52:49.0
+0100
@@ -1193,8 +1193,7 @@ static BOOL load_and_init_quota(ntfs_vol
return FALSE;
}
/* We do not care for the type of match that was found. */
- if (name)
- kfree(name);
+ kfree(name);
/* Get the inode. */
tmp_ino = ntfs_iget(vol->sb, MREF(mref));
if (IS_ERR(tmp_ino) || is_bad_inode(tmp_ino)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> It's the new rock-ridge bounds checking.
Try this, please?
diff -puN fs/isofs/rock.c~rock-handle-directory-overflows-fix fs/isofs/rock.c
--- 25/fs/isofs/rock.c~rock-handle-directory-overflows-fix Fri Mar 25
14:21:32 2005
+++ 25-akpm/fs/isofs/rock.c Fri Mar 25 14:22:01 2005
@@ -218,12 +218,12 @@ repeat:
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(, sig))
+ goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto eio; /* corrupted isofs */
- if (rock_check_overflow(, sig))
- goto eio;
switch (sig) {
case SIG('R', 'R'):
@@ -316,12 +316,12 @@ repeat:
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(, sig))
+ goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto eio; /* corrupted isofs */
- if (rock_check_overflow(, sig))
- goto eio;
switch (sig) {
#ifndef CONFIG_ZISOFS /* No flag for SF or ZF */
@@ -694,12 +694,12 @@ repeat:
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(, sig))
+ goto out;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto out; /* corrupted isofs */
- if (rock_check_overflow(, sig))
- goto out;
switch (sig) {
case SIG('R', 'R'):
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove redundant NULL pointer checks prior to calling kfree() in fs/nfsd/
(please keep me on CC)
checking for NULL before calling kfree() is redundant and needlessly
enlarges the kernel image, let's get rid of those checks.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/nfsd/export.c 2005-03-21 23:12:41.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/nfsd/export.c 2005-03-25 22:48:11.0
+0100
@@ -189,8 +189,7 @@ static int expkey_parse(struct cache_det
out:
if (dom)
auth_domain_put(dom);
- if (buf)
- kfree(buf);
+ kfree(buf);
return err;
}
@@ -426,8 +425,7 @@ static int svc_export_parse(struct cache
path_release();
if (dom)
auth_domain_put(dom);
- if (buf)
- kfree(buf);
+ kfree(buf);
return err;
}
--- linux-2.6.12-rc1-mm3-orig/fs/nfsd/nfs4xdr.c 2005-03-25 15:28:59.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/nfsd/nfs4xdr.c 2005-03-25 22:49:53.0
+0100
@@ -151,8 +151,7 @@ u32 *read_buf(struct nfsd4_compoundargs
if (nbytes <= sizeof(argp->tmp))
p = argp->tmp;
else {
- if (argp->tmpp)
- kfree(argp->tmpp);
+ kfree(argp->tmpp);
p = argp->tmpp = kmalloc(nbytes, GFP_KERNEL);
if (!p)
return NULL;
@@ -2474,10 +2473,8 @@ void nfsd4_release_compoundargs(struct n
kfree(args->ops);
args->ops = args->iops;
}
- if (args->tmpp) {
- kfree(args->tmpp);
- args->tmpp = NULL;
- }
+ kfree(args->tmpp);
+ args->tmpp = NULL;
while (args->to_free) {
struct tmpbuf *tb = args->to_free;
args->to_free = tb->next;
--- linux-2.6.12-rc1-mm3-orig/fs/nfsd/nfscache.c2005-03-21
23:12:41.0 +0100
+++ linux-2.6.12-rc1-mm3/fs/nfsd/nfscache.c 2005-03-25 22:50:14.0
+0100
@@ -93,8 +93,7 @@ nfsd_cache_shutdown(void)
cache_disabled = 1;
- if (hash_list)
- kfree (hash_list);
+ kfree(hash_list);
hash_list = NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: OOM problems on 2.6.12-rc1 with many fsx tests
On Fri, 2005-03-25 at 13:56, Andrew Morton wrote: > Mingming Cao <[EMAIL PROTECTED]> wrote: > > > > I run into OOM problem again on 2.6.12-rc1. I run some(20) fsx tests on > > 2.6.12-rc1 kernel(and 2.6.11-mm4) on ext3 filesystem, after about 10 > > hours the system hit OOM, and OOM keep killing processes one by one. I > > could reproduce this problem very constantly on a 2 way PIII 700MHZ with > > 512MB RAM. Also the problem could be reproduced on running the same test > > on reiser fs. > > > > The fsx command is: > > > > ./fsx -c 10 -n -r 4096 -w 4096 /mnt/test/foo1 & > > I was able to reproduce this on ext3. Seven instances of the above leaked > 10-15MB over 10 hours. All of it permanently stuck on the LRU. > > I'll continue to poke at it - see what kernel it started with, which > filesystems it affects, whether it happens on UP&&!PREEMPT, etc. Not a > quick process. I reproduced *similar* issue with 2.6.11. The reason I say similar, is there is no OOM kill, but very low free memory and machine doesn't respond at all. (I booted my machine with 256M memory and ran 20 copies of fsx on ext3). Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] get rid of redundant checks for NULL before kfree() in fs/jffs/
There's no need to check for NULL before calling kfree().
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/jffs/intrep.c 2005-03-21 23:12:41.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/jffs/intrep.c 2005-03-25 22:47:29.0
+0100
@@ -1693,9 +1693,7 @@ jffs_find_child(struct jffs_file *dir, c
}
printk("jffs_find_child(): Didn't find the file \"%s\".\n",
(copy ? copy : ""));
- if (copy) {
- kfree(copy);
- }
+ kfree(copy);
});
return f;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Separate platform device name from platform device number
On Fri, Mar 25, 2005 at 09:03:57PM +, Russell King wrote: > > It would be trivial to treat them both as foobar0 and have the > > registration succeed for whoever gets it first, but I could see that this > > would be problematic in the serial8250 case. On the other hand, this is > > then serial8250's problem. > > Thank you for ignoring the other case of i82385 to justify your point > of view of it being just a single driver problem. > I didn't ignore it, I said that this was useful for anything that had device names ending in numbers. The above was just in reply to what you had pointed out about the serial8250 behaviour. Thank you for missing the point though. > Maybe you can work out a patch to fix up this mess? > Yes, I'll hack something together in the morning. pgpsXpFv90phM.pgp Description: PGP signature
[PATCH] get rid of NULL pointer checks we don't need before kfree in fs/hpfs/
There's no need to check for NULL before calling kfree().
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/hpfs/dnode.c 2005-03-21 23:12:40.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/hpfs/dnode.c2005-03-25 22:44:39.0
+0100
@@ -244,12 +244,12 @@ static int hpfs_add_to_dnode(struct inod
go_up:
if (namelen >= 256) {
hpfs_error(i->i_sb, "hpfs_add_to_dnode: namelen == %d",
namelen);
- if (nd) kfree(nd);
+ kfree(nd);
kfree(nname);
return 1;
}
if (!(d = hpfs_map_dnode(i->i_sb, dno, ))) {
- if (nd) kfree(nd);
+ kfree(nd);
kfree(nname);
return 1;
}
@@ -257,7 +257,7 @@ static int hpfs_add_to_dnode(struct inod
if (hpfs_sb(i->i_sb)->sb_chk)
if (hpfs_stop_cycles(i->i_sb, dno, , ,
"hpfs_add_to_dnode")) {
hpfs_brelse4();
- if (nd) kfree(nd);
+ kfree(nd);
kfree(nname);
return 1;
}
@@ -270,7 +270,7 @@ static int hpfs_add_to_dnode(struct inod
for_all_poss(i, hpfs_pos_subst, 5, t + 1);
hpfs_mark_4buffers_dirty();
hpfs_brelse4();
- if (nd) kfree(nd);
+ kfree(nd);
kfree(nname);
return 0;
}
--- linux-2.6.12-rc1-mm3-orig/fs/hpfs/super.c 2005-03-21 23:12:40.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/hpfs/super.c2005-03-25 22:45:43.0
+0100
@@ -75,7 +75,7 @@ void hpfs_error(struct super_block *s, c
} else if (s->s_flags & MS_RDONLY) printk("; going on - but
anything won't be destroyed because it's read-only\n");
else printk("; corrupted filesystem mounted read/write - your
computer will explode within 20 seconds ... but you wanted it so!\n");
} else printk("\n");
- if (buf) kfree(buf);
+ kfree(buf);
hpfs_sb(s)->sb_was_error = 1;
}
@@ -102,8 +102,8 @@ int hpfs_stop_cycles(struct super_block
static void hpfs_put_super(struct super_block *s)
{
struct hpfs_sb_info *sbi = hpfs_sb(s);
- if (sbi->sb_cp_table) kfree(sbi->sb_cp_table);
- if (sbi->sb_bmp_dir) kfree(sbi->sb_bmp_dir);
+ kfree(sbi->sb_cp_table);
+ kfree(sbi->sb_bmp_dir);
unmark_dirty(s);
s->s_fs_info = NULL;
kfree(sbi);
@@ -654,8 +654,8 @@ bail3: brelse(bh1);
bail2: brelse(bh0);
bail1:
bail0:
- if (sbi->sb_bmp_dir) kfree(sbi->sb_bmp_dir);
- if (sbi->sb_cp_table) kfree(sbi->sb_cp_table);
+ kfree(sbi->sb_bmp_dir);
+ kfree(sbi->sb_cp_table);
s->s_fs_info = NULL;
kfree(sbi);
return -EINVAL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kfree() NULL pointer cleanups - no need to check - fs/ext3/
kfree() handles NULL pointers fine - checking is redundant.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/ext3/acl.c 2005-03-02 08:37:55.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ext3/acl.c 2005-03-25 22:41:41.0 +0100
@@ -197,8 +197,7 @@ ext3_get_acl(struct inode *inode, int ty
acl = NULL;
else
acl = ERR_PTR(retval);
- if (value)
- kfree(value);
+ kfree(value);
if (!IS_ERR(acl)) {
switch(type) {
@@ -267,8 +266,7 @@ ext3_set_acl(handle_t *handle, struct in
error = ext3_xattr_set_handle(handle, inode, name_index, "",
value, size, 0);
- if (value)
- kfree(value);
+ kfree(value);
if (!error) {
switch(type) {
case ACL_TYPE_ACCESS:
--- linux-2.6.12-rc1-mm3-orig/fs/ext3/super.c 2005-03-25 15:28:59.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ext3/super.c2005-03-25 22:42:53.0
+0100
@@ -395,10 +395,8 @@ static void ext3_put_super (struct super
percpu_counter_destroy(>s_dirs_counter);
brelse(sbi->s_sbh);
#ifdef CONFIG_QUOTA
- for (i = 0; i < MAXQUOTAS; i++) {
- if (sbi->s_qf_names[i])
- kfree(sbi->s_qf_names[i]);
- }
+ for (i = 0; i < MAXQUOTAS; i++)
+ kfree(sbi->s_qf_names[i]);
#endif
/* Debugging code just in case the in-memory inode orphan list
@@ -883,10 +881,8 @@ clear_qf_name:
"quota turned on.\n");
return 0;
}
- if (sbi->s_qf_names[qtype]) {
- kfree(sbi->s_qf_names[qtype]);
- sbi->s_qf_names[qtype] = NULL;
- }
+ kfree(sbi->s_qf_names[qtype]);
+ sbi->s_qf_names[qtype] = NULL;
break;
case Opt_jqfmt_vfsold:
sbi->s_jquota_fmt = QFMT_VFS_OLD;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
(Please dont' edit the cc line. Just do reply-to-all) "Jason Munro" <[EMAIL PROTECTED]> wrote: > > > [ 146.301026] rock: directory entry would overflow storage > > [ 146.301044] rock: sig=0x5245, size=8, remaining=0 > > [ 158.388397] rock: directory entry would overflow storage > > [ 158.388415] rock: sig=0x5850, size=36, remaining=34 > > [EMAIL PROTECTED] steven]# > > > Same results with mm3 here, though mm2 will not boot on my machine so I'm > not sure about that. 2.6.12-rc1 works fine, rc1-mm3 successfully mounts the > cdrom device but shows no contents. Releveant dmsesg output: > > rock: directory entry would overflow storage > rock: sig=0x4543, size=28, remaining=0 > rock: directory entry would overflow storage Seems that I am unable to read. It's the new rock-ridge bounds checking. It worked for me. Is someone able to get an image of a failing filesystem into my hands? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] linux-libc-headers 2.6.11.1
Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
- small (but important) fix in netfilter
- added cleaned up mtd/* userland headers
- massive change to use types from linux/types.h and not to pollute the
namespace
- use gcc emitted __mips64 instead of CONFIG_MIPS{32,64}
I've missed one change in netfilter_ipv4/ip_nat.h when doing 2.6.11.0 which
resulted in broken builds of iptables (so I've been told). Well, these things
might happen from time to time.
As to the last two changes, Erik Andersen provided a script that did them all.
The __mips64 thing is really nice since it removes dependency from
linux/config.h and still works as expected. Wonder if gcc emits other
(potentially) usefull definitions...
Happy Easter.
--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] no need to check for NULL before calling kfree() - fs/ext2/
(please keep me on CC)
kfree() handles NULL fine, to check is redundant.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/ext2/acl.c 2005-03-02 08:38:18.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ext2/acl.c 2005-03-25 22:41:07.0 +0100
@@ -194,8 +194,7 @@ ext2_get_acl(struct inode *inode, int ty
acl = NULL;
else
acl = ERR_PTR(retval);
- if (value)
- kfree(value);
+ kfree(value);
if (!IS_ERR(acl)) {
switch(type) {
@@ -262,8 +261,7 @@ ext2_set_acl(struct inode *inode, int ty
error = ext2_xattr_set(inode, name_index, "", value, size, 0);
- if (value)
- kfree(value);
+ kfree(value);
if (!error) {
switch(type) {
case ACL_TYPE_ACCESS:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/4] create mm/Kconfig for arch-independent memory options
With sparsemem and memory hotplug there are quite a few options that we kept adding identically in several different architectures. This new file allows some of these to be consolidated. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Signed-off-by: Dave Hansen <[EMAIL PROTECTED]> --- memhotplug-dave/mm/Kconfig | 41 + 1 files changed, 41 insertions(+) diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-03-25 08:08:22.0 -0800 +++ memhotplug-dave/mm/Kconfig 2005-03-25 08:08:22.0 -0800 @@ -0,0 +1,41 @@ +choice + prompt "Memory model" + default FLATMEM + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT + +config FLATMEM + bool "Flat Memory" + depends on !ARCH_DISCONTIGMEM_ENABLE || ARCH_FLATMEM_ENABLE + help + This option allows you to change some of the ways that + Linux manages its memory internally. Most users will + only have one option here: FLATMEM. This is normal + and a correct option. + + Some users of more advanced features like NUMA and + memory hotplug may have different options here. + DISCONTIGMEM is an more mature, better tested system, + but is incompatible with memory hotplug and may suffer + decreased performance over SPARSEMEM. If unsure between + "Sparse Memory" and "Discontiguous Memory", choose + "Discontiguous Memory". + + If unsure, choose FLATMEM. + +config DISCONTIGMEM + bool "Discontigious Memory" + depends on ARCH_DISCONTIGMEM_ENABLE + help + If unsure, choose this option over "Sparse Memory". + +endchoice + +# +# Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's +# to represent different areas of memory. This variable allows +# those dependencies to exist individually. +# +config NEED_MULTIPLE_NODES + def_bool y + depends on DISCONTIGMEM || NUMA _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM problems on 2.6.12-rc1 with many fsx tests
Mingming Cao <[EMAIL PROTECTED]> wrote: > > I run into OOM problem again on 2.6.12-rc1. I run some(20) fsx tests on > 2.6.12-rc1 kernel(and 2.6.11-mm4) on ext3 filesystem, after about 10 > hours the system hit OOM, and OOM keep killing processes one by one. I > could reproduce this problem very constantly on a 2 way PIII 700MHZ with > 512MB RAM. Also the problem could be reproduced on running the same test > on reiser fs. > > The fsx command is: > > ./fsx -c 10 -n -r 4096 -w 4096 /mnt/test/foo1 & I was able to reproduce this on ext3. Seven instances of the above leaked 10-15MB over 10 hours. All of it permanently stuck on the LRU. I'll continue to poke at it - see what kernel it started with, which filesystems it affects, whether it happens on UP&&!PREEMPT, etc. Not a quick process. Given that you also saw it on reiserfs, it might be a bug in the core mmap/truncate/unmap handling. We'll see. > I also see fsx tests start to generating report about read bad data > about the tests have run for about 9 hours(one hour before of the OOM > happen). I haven't noticed anything like that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 2/4] make each arch use mm/Kconfig
With sparsemem being introduced, we need a central place for new memory-related .config options: mm/Kconfig. For all architectures, this just means that you'll see a "Memory Model" choice in your architecture menu. For those that implement DISCONTIGMEM, you may eventually want to make your ARCH_DISCONTIGMEM_ENABLE a "def_bool y" and make your users select DISCONTIGMEM right out of the new choice menu. The only disadvantage might be if you have some specific things that you need in your help option for DISCONTIGMEM. The new option, CONFIG_FLATMEM, is there to enable us to detangle NUMA and DISCONTIGMEM. This is a requirement for sparsemem because sparsemem uses the NUMA code without the presence of DISCONTIGMEM. The sparsemem patches use CONFIG_FLATMEM in generic code, so this patch is a requirement before applying them. Almost all places that used to do '#ifndef CONFIG_DISCONTIGMEM' should use '#ifdef CONFIG_FLATMEM' instead. Signed-off-by: Dave Hansen <[EMAIL PROTECTED]> --- memhotplug-dave/arch/alpha/Kconfig |4 +++- memhotplug-dave/arch/arm/Kconfig |4 +++- memhotplug-dave/arch/arm26/Kconfig |2 ++ memhotplug-dave/arch/cris/Kconfig |2 ++ memhotplug-dave/arch/frv/Kconfig |2 ++ memhotplug-dave/arch/h8300/Kconfig.cpu |3 +++ memhotplug-dave/arch/i386/Kconfig |4 +++- memhotplug-dave/arch/ia64/Kconfig |4 +++- memhotplug-dave/arch/m32r/Kconfig |4 +++- memhotplug-dave/arch/m68k/Kconfig |2 ++ memhotplug-dave/arch/m68knommu/Kconfig |2 ++ memhotplug-dave/arch/mips/Kconfig |6 +- memhotplug-dave/arch/parisc/Kconfig|8 +++- memhotplug-dave/arch/ppc/Kconfig |2 ++ memhotplug-dave/arch/ppc64/Kconfig |4 +++- memhotplug-dave/arch/s390/Kconfig |2 ++ memhotplug-dave/arch/sh/Kconfig|8 +++- memhotplug-dave/arch/sh64/Kconfig |2 ++ memhotplug-dave/arch/sparc/Kconfig |2 ++ memhotplug-dave/arch/sparc64/Kconfig |2 ++ memhotplug-dave/arch/um/Kconfig|1 + memhotplug-dave/arch/v850/Kconfig |2 ++ memhotplug-dave/arch/x86_64/Kconfig|4 +++- 23 files changed, 66 insertions(+), 10 deletions(-) diff -puN arch/alpha/Kconfig~A7-make-each-arch-use-mm-Kconfig arch/alpha/Kconfig --- memhotplug/arch/alpha/Kconfig~A7-make-each-arch-use-mm-Kconfig 2005-03-25 08:08:22.0 -0800 +++ memhotplug-dave/arch/alpha/Kconfig 2005-03-25 08:08:22.0 -0800 @@ -505,7 +505,7 @@ config NR_CPUS depends on SMP default "64" -config DISCONTIGMEM +config ARCH_DISCONTIGMEM_ENABLE bool "Discontiguous Memory Support (EXPERIMENTAL)" depends on EXPERIMENTAL help @@ -514,6 +514,8 @@ config DISCONTIGMEM or have huge holes in the physical address space for other reasons. See for more. +source "mm/Kconfig" + config NUMA bool "NUMA Support (EXPERIMENTAL)" depends on DISCONTIGMEM diff -puN arch/arm/Kconfig~A7-make-each-arch-use-mm-Kconfig arch/arm/Kconfig --- memhotplug/arch/arm/Kconfig~A7-make-each-arch-use-mm-Kconfig 2005-03-25 08:08:22.0 -0800 +++ memhotplug-dave/arch/arm/Kconfig2005-03-25 08:08:22.0 -0800 @@ -289,7 +289,7 @@ config NR_CPUS depends on SMP default "4" -config DISCONTIGMEM +config ARCH_DISCONTIGMEM_ENABLE bool depends on ARCH_EDB7211 || ARCH_SA1100 || (ARCH_LH7A40X && !LH7A40X_CONTIGMEM) default y @@ -299,6 +299,8 @@ config DISCONTIGMEM or have huge holes in the physical address space for other reasons. See for more. +source "mm/Kconfig" + # Now handle the bus types config PCI bool "PCI support" if ARCH_INTEGRATOR_AP diff -puN arch/arm26/Kconfig~A7-make-each-arch-use-mm-Kconfig arch/arm26/Kconfig --- memhotplug/arch/arm26/Kconfig~A7-make-each-arch-use-mm-Kconfig 2005-03-25 08:08:22.0 -0800 +++ memhotplug-dave/arch/arm26/Kconfig 2005-03-25 08:08:22.0 -0800 @@ -175,6 +175,8 @@ config CMDLINE time by entering them here. As a minimum, you should specify the memory size and the root device (e.g., mem=64M root=/dev/nfs). +source "mm/Kconfig" + endmenu source "drivers/base/Kconfig" diff -puN arch/cris/Kconfig~A7-make-each-arch-use-mm-Kconfig arch/cris/Kconfig --- memhotplug/arch/cris/Kconfig~A7-make-each-arch-use-mm-Kconfig 2005-03-25 08:08:22.0 -0800 +++ memhotplug-dave/arch/cris/Kconfig 2005-03-25 08:08:22.0 -0800 @@ -74,6 +74,8 @@ config PREEMPT Say Y here if you are building a kernel for a desktop, embedded or real-time system. Say N if you are unsure. +source mm/Kconfig + endmenu menu "Hardware setup" diff -puN arch/frv/Kconfig~A7-make-each-arch-use-mm-Kconfig arch/frv/Kconfig --- memhotplug/arch/frv/Kconfig~A7-make-each-arch-use-mm-Kconfig 2005-03-25 08:08:22.0 -0800 +++ memhotplug-dave/arch/frv/Kconfig
Re: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:52 +, Russell King wrote: > On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: > > On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > > > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > > > On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > > > > > Users need to be re-educated _not_ to use ksymoops. > > > > > > > > How about changing the fscking docs to not tell users to use it? > > > > > > Would be useful. The "fscking" problem is that no one actually owns the > > > documents, so there's no central focus to keep them up to date. > > > > > > > Are you serious? So Documentation/sound/alsa/* isn't maintained by the > > ALSA maintainers? > > Last I checked, Documentation/oops-tracking.txt wasn't under > Documentation/sound/alsa. It seems obvious to me, but maybe it isn't > obvious to others, as your message appears to suggest. > No, I just misread your message as "none of the docs are maintained" rather than "oops-tracking.txt is not maintained". > As far as the question of ALSA documentation being up to date, that's > one set of directories in the kernel tree I've _never_ looked at, so > can't comment. Sorry. > The ALSA docs are in fact up to date. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 4/4] Introduce new Kconfig option for NUMA or DISCONTIG
There is some confusion that arose when working on SPARSEMEM patch
between what is needed for DISCONTIG vs. NUMA.
Multiple pg_data_t's are needed for DISCONTIGMEM or NUMA,
independently. All of the current NUMA implementations require an
implementation of DISCONTIG. Because of this, quite a lot of code
which is really needed for NUMA is actually under DISCONTIG #ifdefs.
For SPARSEMEM, we changed some of these #ifdefs to CONFIG_NUMA, but
that broke the DISCONTIG=y and NUMA=n case.
Introducing this new NEED_MULTIPLE_NODES config option allows code
that is needed for both NUMA or DISCONTIG to be separated out from
code that is specific to DISCONTIG.
One great advantage of this approach is that it doesn't require
every architecture to be converted over. All of the current
implementations should "just work", only the ones implementing
SPARSEMEM will have to be fixed up.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/include/linux/mmzone.h |6 +++---
memhotplug-dave/mm/page_alloc.c|6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff -puN include/linux/mmzone.h~B-sparse-140-separate-NUMA-DISCONTIG
include/linux/mmzone.h
--- memhotplug/include/linux/mmzone.h~B-sparse-140-separate-NUMA-DISCONTIG
2005-03-25 08:08:25.0 -0800
+++ memhotplug-dave/include/linux/mmzone.h 2005-03-25 08:08:25.0
-0800
@@ -385,7 +385,7 @@ int lowmem_reserve_ratio_sysctl_handler(
/* Returns the number of the current Node. */
#define numa_node_id() (cpu_to_node(_smp_processor_id()))
-#ifndef CONFIG_DISCONTIGMEM
+#ifndef CONFIG_NEED_MULTIPLE_NODES
extern struct pglist_data contig_page_data;
#define NODE_DATA(nid) (_page_data)
@@ -393,11 +393,11 @@ extern struct pglist_data contig_page_da
#define MAX_NODES_SHIFT1
#define pfn_to_nid(pfn)(0)
-#else /* CONFIG_DISCONTIGMEM */
+#else /* CONFIG_NEED_MULTIPLE_NODES */
#include
-#endif /* !CONFIG_DISCONTIGMEM */
+#endif /* !CONFIG_NEED_MULTIPLE_NODES */
#if BITS_PER_LONG == 32 || defined(ARCH_HAS_ATOMIC_UNSIGNED)
/*
diff -puN mm/page_alloc.c~B-sparse-140-separate-NUMA-DISCONTIG mm/page_alloc.c
--- memhotplug/mm/page_alloc.c~B-sparse-140-separate-NUMA-DISCONTIG
2005-03-25 08:08:25.0 -0800
+++ memhotplug-dave/mm/page_alloc.c 2005-03-25 08:08:25.0 -0800
@@ -1765,18 +1765,18 @@ void __init free_area_init_node(int nid,
free_area_init_core(pgdat, zones_size, zholes_size);
}
-#ifndef CONFIG_DISCONTIGMEM
+#ifndef CONFIG_NEED_MULTIPLE_NODES
static bootmem_data_t contig_bootmem_data;
struct pglist_data contig_page_data = { .bdata = _bootmem_data };
EXPORT_SYMBOL(contig_page_data);
+#endif
void __init free_area_init(unsigned long *zones_size)
{
- free_area_init_node(0, _page_data, zones_size,
+ free_area_init_node(0, NODE_DATA(0), zones_size,
__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
}
-#endif
#ifdef CONFIG_PROC_FS
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 3/4] update all defconfigs for ARCH_DISCONTIGMEM_ENABLE
This will at least suppress one prompt that users would have received the first time they compile with the new DISCONTIG arch option. They'll still get the "Memory Model" prompt, but 99% of them will have the default work there. Signed-off-by: Dave Hansen <[EMAIL PROTECTED]> --- arch/x86_64/defconfig|0 memhotplug-dave/arch/alpha/defconfig |2 +- memhotplug-dave/arch/ia64/configs/sn2_defconfig |2 +- memhotplug-dave/arch/ia64/defconfig |2 +- memhotplug-dave/arch/mips/configs/ip27_defconfig |2 +- memhotplug-dave/arch/ppc64/configs/pSeries_defconfig |2 +- memhotplug-dave/arch/ppc64/defconfig |2 +- 7 files changed, 6 insertions(+), 6 deletions(-) diff -puN arch/alpha/defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/alpha/defconfig --- memhotplug/arch/alpha/defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG 2005-03-25 08:08:24.0 -0800 +++ memhotplug-dave/arch/alpha/defconfig2005-03-25 08:08:24.0 -0800 @@ -96,7 +96,7 @@ CONFIG_ALPHA_CORE_AGP=y CONFIG_ALPHA_BROKEN_IRQ_MASK=y CONFIG_EISA=y # CONFIG_SMP is not set -# CONFIG_DISCONTIGMEM is not set +# CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set CONFIG_VERBOSE_MCHECK=y CONFIG_VERBOSE_MCHECK_ON=1 CONFIG_PCI_LEGACY_PROC=y diff -puN arch/arm/configs/a5k_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/a5k_defconfig diff -puN arch/arm/configs/assabet_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/assabet_defconfig diff -puN arch/arm/configs/badge4_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/badge4_defconfig diff -puN arch/arm/configs/cerfcube_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/cerfcube_defconfig diff -puN arch/arm/configs/clps7500_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/clps7500_defconfig diff -puN arch/arm/configs/edb7211_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/edb7211_defconfig diff -puN arch/arm/configs/footbridge_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/footbridge_defconfig diff -puN arch/arm/configs/fortunet_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/fortunet_defconfig diff -puN arch/arm/configs/h3600_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/h3600_defconfig diff -puN arch/arm/configs/hackkit_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/hackkit_defconfig diff -puN arch/arm/configs/jornada720_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/jornada720_defconfig diff -puN arch/arm/configs/lart_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/lart_defconfig diff -puN arch/arm/configs/lpd7a400_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/lpd7a400_defconfig diff -puN arch/arm/configs/lpd7a404_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/lpd7a404_defconfig diff -puN arch/arm/configs/lusl7200_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/lusl7200_defconfig diff -puN arch/arm/configs/neponset_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/neponset_defconfig diff -puN arch/arm/configs/omnimeter_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/omnimeter_defconfig diff -puN arch/arm/configs/pleb_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/pleb_defconfig diff -puN arch/arm/configs/shannon_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/shannon_defconfig diff -puN arch/arm/configs/simpad_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/arm/configs/simpad_defconfig diff -puN arch/ia64/configs/sn2_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/ia64/configs/sn2_defconfig --- memhotplug/arch/ia64/configs/sn2_defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG 2005-03-25 08:08:24.0 -0800 +++ memhotplug-dave/arch/ia64/configs/sn2_defconfig 2005-03-25 08:08:24.0 -0800 @@ -78,7 +78,7 @@ CONFIG_IA64_L1_CACHE_SHIFT=7 CONFIG_NUMA=y CONFIG_VIRTUAL_MEM_MAP=y CONFIG_HOLES_IN_ZONE=y -CONFIG_DISCONTIGMEM=y +CONFIG_ARCH_DISCONTIGMEM_ENABLE=y # CONFIG_IA64_CYCLONE is not set CONFIG_IOSAPIC=y CONFIG_IA64_SGI_SN_SIM=y diff -puN arch/ia64/defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG arch/ia64/defconfig --- memhotplug/arch/ia64/defconfig~A8-update-all-defconfigs-for-ARCH...DISCONTIG 2005-03-25 08:08:24.0 -0800 +++ memhotplug-dave/arch/ia64/defconfig 2005-03-25 08:08:24.0 -0800 @@ -77,7 +77,7 @@ CONFIG_IA64_PAGE_SIZE_16KB=y CONFIG_IA64_L1_CACHE_SHIFT=7 CONFIG_NUMA=y CONFIG_VIRTUAL_MEM_MAP=y -CONFIG_DISCONTIGMEM=y +CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
Re: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: > On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > > On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > > > > Users need to be re-educated _not_ to use ksymoops. > > > > > > How about changing the fscking docs to not tell users to use it? > > > > Would be useful. The "fscking" problem is that no one actually owns the > > documents, so there's no central focus to keep them up to date. > > > > Are you serious? So Documentation/sound/alsa/* isn't maintained by the > ALSA maintainers? Last I checked, Documentation/oops-tracking.txt wasn't under Documentation/sound/alsa. It seems obvious to me, but maybe it isn't obvious to others, as your message appears to suggest. As far as the question of ALSA documentation being up to date, that's one set of directories in the kernel tree I've _never_ looked at, so can't comment. Sorry. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
On 3:22:52 pm 03/25/05 Steven Cole <[EMAIL PROTECTED]> wrote: > Same results, -mm2 broken, and -mm1 reads the disk. I even tried > other CD's just to make sure I didn't have something weird. Same > results. > [EMAIL PROTECTED] steven]# dmesg | tail > [ 51.205871] EXT3 FS on hda6, internal journal > [ 51.205880] EXT3-fs: mounted filesystem with ordered data mode. > [ 51.234132] kjournald starting. Commit interval 5 seconds > [ 51.234544] EXT3 FS on hda7, internal journal > [ 51.234553] EXT3-fs: mounted filesystem with ordered data mode. > [ 58.357329] PCI: Found IRQ 5 for device :01:0c.0 > [ 146.301026] rock: directory entry would overflow storage > [ 146.301044] rock: sig=0x5245, size=8, remaining=0 > [ 158.388397] rock: directory entry would overflow storage > [ 158.388415] rock: sig=0x5850, size=36, remaining=34 > [EMAIL PROTECTED] steven]# Same results with mm3 here, though mm2 will not boot on my machine so I'm not sure about that. 2.6.12-rc1 works fine, rc1-mm3 successfully mounts the cdrom device but shows no contents. Releveant dmsesg output: rock: directory entry would overflow storage rock: sig=0x4543, size=28, remaining=0 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=27 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=26 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=27 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=26 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=26 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=26 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=27 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=26 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=26 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=26 rock: directory entry would overflow storage rock: sig=0x5850, size=36, remaining=27 The machine is a Toshiba P35-S609 laptop the cdrom device is: MATSHITADVD-RAM UJ-820S, ATAPI CD/DVD-ROM drive Kernel config is attached. \__ Jason Munro \__ [EMAIL PROTECTED] \__ http://hastymail.sourceforge.net/ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm3 # Fri Mar 25 12:32:46 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y
Re: 2.6.12-rc1-mm3 (cannot read cd-rom, 2.6.12-rc1 is OK)
Steven Cole <[EMAIL PROTECTED]> wrote: > > >> > >> I found a few more minutes to test two more kernels. The problem > >> first occured with 2.6.12-rc1-mm2: > >> > >> 2.6.12-rc1 reads the cd-rom OK as reported earlier > >> 2.6.12-rc1-mm1 also reads the cd-rom OK > >> 2.6.12-rc1-mm2 broken same as -mm3 described as above > >> 2.6.12-rc1-mm3 broken as reported earlier > > > > > > Are you really really sure about that? -mm3 included both the bk-ide-dev > > tree and the isofs changes. 2.6.12-rc1-mm2 had neither. > > > > Just to be really really sure, I repeated the tests. I even checked > that the image/label combination in /etc/lilo.conf was what I intended, > but the uname -r should show what's what. > > Same results, -mm2 broken, and -mm1 reads the disk. I even tried > other CD's just to make sure I didn't have something weird. Same results. OK, thanks. It would be interesting to copy a CD to hard disk (under -mm1) and see if it works OK with the loopback driver. Also, boot into -mm2 and do a `cmp' of the cdrom with the image which is on hard-disk. This should help us work out whether it's isofs, the driver, the VFS or whatever. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > > > Users need to be re-educated _not_ to use ksymoops. > > > > How about changing the fscking docs to not tell users to use it? > > Would be useful. The "fscking" problem is that no one actually owns the > documents, so there's no central focus to keep them up to date. > Are you serious? So Documentation/sound/alsa/* isn't maintained by the ALSA maintainers? Wow, this would explain why all Linux documentation is at least 2 years out of date. > Maybe we need a docfsck? 8) > > I certainly don't have authority to tell x86 people not to use ksymoops. > Therefore, I think my suggested change (which up until recently I thought > was an ARM only problem) should be done by someone else. > At least from my experience, ksymoops is useless on x86 for 2.6 kernels. Here is a patch to finally bring oops-tracing.txt into the 2.6 era. :-P Sugned-Off-By: Lee Revell <[EMAIL PROTECTED]> Lee --- Documentation/oops-tracing.txt~ 2005-03-17 20:34:06.0 -0500 +++ Documentation/oops-tracing.txt 2005-03-25 16:41:07.0 -0500 @@ -1,23 +1,22 @@ +NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format +(from dmesg, etc). Ignore any references in this or other docs to "decoding +the Oops" or "running it through ksymoops". If you post an Oops fron 2.6 that +has been run through ksymoops, people will just tell you to repost it. + Quick Summary - -Install ksymoops from -ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops -Read the ksymoops man page. -ksymoops < the_oops.txt - -and send the output the maintainer of the kernel area that seems to be -involved with the problem, not to the ksymoops maintainer. Don't worry -too much about getting the wrong person. If you are unsure send it to -the person responsible for the code relevant to what you were doing. -If it occurs repeatably try and describe how to recreate it. Thats -worth even more than the oops +Find the Oops and send it to the maintainer of the kernel area that seems to be +involved with the problem. Don't worry too much about getting the wrong person. +If you are unsure send it to the person responsible for the code relevant to +what you were doing. If it occurs repeatably try and describe how to recreate +it. That's worth even more than the oops. If you are totally stumped as to whom to send the report, send it to [EMAIL PROTECTED] Thanks for your help in making Linux as stable as humanly possible. -Where is the_oops.txt? +Where is the Oops? -- Normally the Oops text is read from the kernel buffers by klogd and @@ -43,15 +42,14 @@ them yourself. Search kernel archives for kmsgdump, lkcd and oops+smram. -No matter how you capture the log output, feed the resulting file to -ksymoops along with /proc/ksyms and /proc/modules that applied at the -time of the crash. /var/log/ksymoops can be useful to capture the -latter, man ksymoops for details. - Full Information +NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it +for historical reasons, and because some of the information in it still +applies. Especially, please ignore any references to ksymoops. + From: Linus Torvalds <[EMAIL PROTECTED]> How to track down an Oops.. [originally a mail to linux-kernel] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
