Re: Linux v2.6.0-test1

Re: Linux v2.6.0-test1

[John Bradford]

> Then you'll just have to wait a few months

Oh well, it just seems strange to be asking people to test
2.6.0-root-my-box, without making the consequences a bit clearer.

John.

Re: Linux v2.6.0-test1

[Dave Jones]

On Mon, Jul 14, 2003 at 12:50:40PM +0100, John Bradford wrote:
 > > Then you'll just have to wait a few months
 > 
 > Oh well, it just seems strange to be asking people to test
 > 2.6.0-root-my-box, without making the consequences a bit clearer.

>From http://www.codemonkey.org.uk/post-halloween-2.5.txt

------ 8< 8< 8< 8< ------
Security concerns.
~~~~~~~~~~~~~~~~~~
Several security issues solved in 2.4 may not yet be forward ported
to 2.5. For this reason 2.5.x kernels should not be tested on
untrusted systems.  Testing known 2.4 exploits and reporting results
is useful.
------ 8< 8< 8< 8< ------


If you don't have the time/energy to trawl linux-kernel, testing the
many zillions of `sploits out there to see what works and what doesn't
may be more fun. (Although most if not all should be failing, so it
may also get boring very quickly). It'd be nice if someone like osdl
could add such testing to nightly regression tests. Some of them may
even be candidates for LTP perhaps ?

		Dave

Re: Linux v2.6.0-test1

[William Lee Irwin III]

On Mon, Jul 14, 2003 at 12:50:40PM +0100, John Bradford wrote:
>> Oh well, it just seems strange to be asking people to test
>> 2.6.0-root-my-box, without making the consequences a bit clearer.

On Mon, Jul 14, 2003 at 12:53:13PM +0100, Dave Jones wrote:
> If you don't have the time/energy to trawl linux-kernel, testing the
> many zillions of `sploits out there to see what works and what doesn't
> may be more fun. (Although most if not all should be failing, so it
> may also get boring very quickly). It'd be nice if someone like osdl
> could add such testing to nightly regression tests. Some of them may
> even be candidates for LTP perhaps ?

Some work has been done here, though I'm not sure how much; I'll try to
get the IBM people involved with it to chime in.


-- wli

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 13:00, William Lee Irwin III wrote:
> Some work has been done here, though I'm not sure how much; I'll try to
> get the IBM people involved with it to chime in.

The IBM india folks (being outside the DMCA zone) went through a long list of 
fixes and propogated them but there are lots of others some pretty critical such
as the fs/exec stuff and proc leaks

Re: Linux v2.6.0-test1

[William Lee Irwin III]

On Llu, 2003-07-14 at 13:00, William Lee Irwin III wrote:
>> Some work has been done here, though I'm not sure how much; I'll try to
>> get the IBM people involved with it to chime in.

On Mon, Jul 14, 2003 at 01:39:44PM +0100, Alan Cox wrote:
> The IBM india folks (being outside the DMCA zone) went through a long list of 
> fixes and propogated them but there are lots of others some pretty critical such
> as the fs/exec stuff and proc leaks

Well, that should cover it. Odd that I've not heard of those two.


-- wli

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 13:47, William Lee Irwin III wrote:
> Well, that should cover it. Odd that I've not heard of those two.

They've had publically discussed fixes, patch files, CAN vulnerability
identifiers and mail to bugtraq. The information is out there but the
2.5 people have been too busy on more fundamental stuff I guess

Re: Linux v2.6.0-test1 [[Fwd: [Full-Disclosure] Linux 2.4.x execve() file read race vulnerability]]

[David R. Piegdon]

this one was posted on full-disclosure a while ago
i think this is what alan cox means with
 fs/exec stuff
:)


----------  Forwarded Message  ----------
From: Paul Starzetz <paul@starzetz.de>
To: bugtraq@securityfocus.com,
 vendor-sec <vendor-sec@lst.de>,
 full-disclosure@lists.netsys.com
Date: Thu, 26 Jun 2003 19:24:23 +0200

Hi people,

again it is time to discover a funny bug inside the Linux execve()
system call.


Details:
- ---------

While looking at the execve() code I've found the following piece of
code (from fs/binfmt_elf.c):

static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs *
regs)
{
    struct file *interpreter = NULL; /* to shut gcc up */

[...]

    retval = kernel_read(bprm->file, elf_ex.e_phoff, (char *)
elf_phdata, size);
    if (retval < 0)
        goto out_free_ph;

    retval = get_unused_fd();
    if (retval < 0)
        goto out_free_ph;
    get_file(bprm->file);
    fd_install(elf_exec_fileno = retval, bprm->file);


So, during the execution of new binary, the opened file descriptor to
the executable is put into the file table of the current (the caller of
execve()) process. This can be exploited creating a file sharing
parent/child pair by means of the clone() syscall and reading the file
descriptor from one of them.

Further, the check for shared files structure (in compute_creds() from
exec.c) is made to late, so even the parent can successfully exit after
playing games on that file descriptor and the child (if setuid) is
executed under full privileges. I wrote a simple setuid binary dump
utility so far, but further implications (due to the complexity of the
execve() syscall) may be possible...


Lets illustrate the vulnerability:

paul@buggy:~> ls -l /bin/ping
- -rws--x--x    1 root     root        29680 Oct 25  2001 /bin/ping

so the setuid ping binary can be only executed by anyone, but not read.

Now we start the suid dumper (while playing with the disk on another
console like cat /usr/bin/* >/dev/null) :

paul@buggy:~> while true ; do ./suiddmp /bin/ping -c 1 127.0.0.1 ; if
test $? -eq 1 ; then exit 1 ; fi; done 2>/dev/null | grep -A5 suc

and after few seconds:

Parent success stating:
uid 0 gid 0 mode 104711 inode 9788 size 29680
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=94 usec

- --- 127.0.0.1 ping statistics ---

paul@buggy:~> ls -l
total 7132
- -rwxr-xr-x    1 paul     users       29680 Jun 26 19:17 suid.dump
[...]

paul@buggy:~> ./suid.dump
Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
            [-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
            [-M mtu discovery hint] [-S sndbuf]
            [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination


Obviously the setuid binary has been duplicated :-) (but with no setuid
flag of course).


Source also available at:

http://www.starzetz.com/paul/suiddmp.c

/ih

-------------------------------------------------------

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 12:50, John Bradford wrote:
> > Then you'll just have to wait a few months
> 
> Oh well, it just seems strange to be asking people to test
> 2.6.0-root-my-box, without making the consequences a bit clearer.

Its 2.6.0 locally root my box, not remotely root my box, although remote
crash bugs exist in at least one situation

Re: Linux v2.6.0-test1

[Kurt Wall]

Quoth John Bradford:
> > Then you'll just have to wait a few months
> 
> Oh well, it just seems strange to be asking people to test
> 2.6.0-root-my-box, without making the consequences a bit clearer.

And it seems equally odd actually to put an unstable kernel on a 
production system.

Kurt
-- 
He had occasional flashes of silence that made his conversation
perfectly delightful.
		-- Sydney Smith

Re: Linux v2.6.0-test1

[Dirk Meul]

Hello!

Using devfs, there are neither device-nodes for the ZIP-drive using
ide-floppy nor for cpuid or msr. Are there any patches i can try (i
didn't find patches for ide-floppy).

Best regards,
-- 
                                  /"\
Dirk Meul                         \ /    ASCII Ribbon Campaign
meul@aixcape.org                   X     Against HTML Mail
                                  / \

Re: Linux v2.6.0-test1

[Martin Schlemmer]

On Tue, 2003-07-15 at 09:52, Dirk Meul wrote:
> Hello!
> 
> Using devfs, there are neither device-nodes for the ZIP-drive using
> ide-floppy nor for cpuid or msr. Are there any patches i can try (i
> didn't find patches for ide-floppy).
> 

Check here:

  http://marc.theaimsgroup.com/?l=linux-kernel&m=105810954902637&w=2


-- 
Martin Schlemmer

Re: Linux v2.6.0-test1

[John Bradford]

> > > The point of the test versions is to make more people realize that they
> > > need testing
> > 
> > Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
>
> No, and several more have been added in 2.6-test only.

As far as I know, they are only information disclosure ones, not
directly exploitable vulnerabilities, or am I wrong?

> > This has been the only major reason for keeping of most of my
> > production machines running 2.4 for quite a while.  If not, can we get
> > the fixes in at the earliest opportunity?
>
> Sure.. send the fixes to Linus

Is anybody even keeping track of this, though?  Picking thorough LKML
to see what did and didn't go in doesn't seem particularly exciting to
me.

John.

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 12:39, John Bradford wrote:
> > > > The point of the test versions is to make more people realize that they
> > > > need testing
> > > 
> > > Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
> >
> > No, and several more have been added in 2.6-test only.
> 
> As far as I know, they are only information disclosure ones, not
> directly exploitable vulnerabilities, or am I wrong?

Last time I checked there were remote DoS attacks and local root attacks
present in 2.5.7x

> > > This has been the only major reason for keeping of most of my
> > > production machines running 2.4 for quite a while.  If not, can we get
> > > the fixes in at the earliest opportunity?
> >
> > Sure.. send the fixes to Linus
> 
> Is anybody even keeping track of this, though?  Picking thorough LKML
> to see what did and didn't go in doesn't seem particularly exciting to
> me.

Then you'll just have to wait a few months

Re: Linux v2.6.0-test1

[Marcelo Tosatti]

On Mon, 14 Jul 2003, Alan Cox wrote:

> On Llu, 2003-07-14 at 12:39, John Bradford wrote:
> > > > > The point of the test versions is to make more people realize that they
> > > > > need testing
> > > >
> > > > Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
> > >
> > > No, and several more have been added in 2.6-test only.
> >
> > As far as I know, they are only information disclosure ones, not
> > directly exploitable vulnerabilities, or am I wrong?
>
> Last time I checked there were remote DoS attacks and local root attacks
> present in 2.5.7x
>
> > > > This has been the only major reason for keeping of most of my
> > > > production machines running 2.4 for quite a while.  If not, can we get
> > > > the fixes in at the earliest opportunity?
> > >
> > > Sure.. send the fixes to Linus
> >
> > Is anybody even keeping track of this, though?  Picking thorough LKML
> > to see what did and didn't go in doesn't seem particularly exciting to
> > me.
>
> Then you'll just have to wait a few months

I will start looking at 2.4 security fixes which are not applied in 2.6.

If someone is already doing that, please tell me.

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 14:56, Marcelo Tosatti wrote:
> > Then you'll just have to wait a few months
> 
> I will start looking at 2.4 security fixes which are not applied in 2.6.
> 
> If someone is already doing that, please tell me.

I'm working on the recent exec and proc stuff. strncpy needs people who can
do their native asm though.

Re: Linux v2.6.0-test1

[Marcelo Tosatti]

On Mon, 14 Jul 2003, Alan Cox wrote:

> On Llu, 2003-07-14 at 14:56, Marcelo Tosatti wrote:
> > > Then you'll just have to wait a few months
> >
> > I will start looking at 2.4 security fixes which are not applied in 2.6.
> >
> > If someone is already doing that, please tell me.
>
> I'm working on the recent exec and proc stuff. strncpy needs people who can
> do their native asm though.

Right. I'll look at any other possible (misc) security problem which is
fixed in 2.4.

Re: Linux v2.6.0-test1

[John Bradford]

> The point of the test versions is to make more people realize that they
> need testing

Are all the known security issues in 2.4 now fixed in 2.6.0-test1?

This has been the only major reason for keeping of most of my
production machines running 2.4 for quite a while.  If not, can we get
the fixes in at the earliest opportunity?

John.

Re: Linux v2.6.0-test1

[Alan Cox]

On Llu, 2003-07-14 at 12:01, John Bradford wrote:
> > The point of the test versions is to make more people realize that they
> > need testing
> 
> Are all the known security issues in 2.4 now fixed in 2.6.0-test1?

No, and several more have been added in 2.6-test only.

> This has been the only major reason for keeping of most of my
> production machines running 2.4 for quite a while.  If not, can we get
> the fixes in at the earliest opportunity?

Sure.. send the fixes to Linus

Linux v2.6.0-test1

[Linus Torvalds]

Ok,
 the naming should be familiar - it's the same deal as with 2.4.0.

One difference is that while 2.4.0 took about 7 months from the pre1 to 
the final release, I hope (and believe) that we have fewer issues facing 
us in the current 2.6.0. But very obviously there are going to be a
few test-releases before the real thing.

The point of the test versions is to make more people realize that they
need testing and get some straggling developers realizing that it's too
late to worry about the next big feature. I'm hoping that Linux vendors
will start offering the test kernels as installation alternatives, and
do things like make upgrade internal machines, so that when the real
2.6.0 does happen, we're all set.

		Linus

---

Summary of changes from v2.5.75 to v2.6.0-test1
============================================

<jcchen:icplus.com.tw>:
  o [netdrvr sundance] increase eeprom read timeout

<taowenhwa:intel.com>:
  o [e100] cu_start: timeout waiting for cu
  o [e100] misc

Alan Cox:
  o genrtc sets owner fields so
  o Remove bogus printk in microcode.c
  o clean up floppy98 a bit
  o dtlk comment fix
  o isurf compile fix
  o axnet can unload with timers live
  o ibmtr can unload with timers live
  o fix up nmclan locking and hang on eject at wrong moment
  o fix further timer in pcmcia stuff
  o Fix remaining g_NCR5380 use of check_region
  o not sure what the author was on
  o AC97 updates from 2.4
  o Add the au1000 driver
  o demo plugin for switching ad1980 ports Dell style
  o Fix security leaks in btaudio
  o Add the ALI5455 driver from 2.4
  o fix security leaks in cmpci
  o Update cs46xx in 2.5 to the newer 2.4 release
  o fix the security leak in dmasound
  o Switch the SB Live! to the new ac97 api
  o fix security leaks and a crash in es1370
  o bring es1371 in line with 2.4
  o fix security leak and crash in esssolo
  o Add Forte Media OSS driver
  o update ITE audio
  o update the i810 audio driver
  o switch maestro3 to new ac97
  o fix security leak in maestro.c
  o fix security leak in msnd_pinnacle.c
  o Add swarm driver for broadcom boards
  o update nec driver to new ac97
  o update trident driver for new ac97 etc
  o fix wrong printk in nm256 audio
  o update via audio driver, make it work on esd add new chips
  o more wrong strlcpy's
  o update ymfpci for new ac97
  o Merge AD1889 driver from 2.4

Alan Stern:
  o USB: Small correction to usb-skeleton.c
  o USB: Updates for unusual_devs.h

Andi Kleen:
  o Deprecate numerical sysctl
  o x86-64 fixes for 2.5.75

Andrew Morton:
  o fix return of compat_sys_sched_getaffinity
  o remove proc_mknod()
  o reiserfs dirty memory accounting fix
  o fix reiserfs for 64bit arches
  o wall_to_monotonic initialization fixes for
  o i_size atomic access: infrastructure
  o i_size atomic access
  o kmap() -> kmap_atomic() in fs/exec.c
  o make CONFIG_KALLSYMS default to "on"
  o misc fixes
  o Set umask correctly for nfsd kernel threads
  o Bug fix in AIO initialization
  o Fix race condition between aio_complete and
  o separate locking for vfsmounts
  o fix for CPU scheduler load distribution
  o NBD: cosmetic cleanups
  o nbd: enhanced diagnostics support
  o nbd: remove unneeded blksize_bits field
  o nbd: initialise the embedded kobject
  o nbd: cleanup PARANOIA usage & code
  o NBD documentation update
  o nbd: remove unneeded nbd_open/nbd_release and refcnt
  o nbd: make nbd and block layer agree about device and
  o JBD: checkpointing optimisations
  o JBD: transaction buffer accounting fix
  o ext3: sync_fs() fix
  o oom killer fixes
  o yenta-socket initialisation fix
  o Fix yenta-socket oops
  o devfs oops fix
  o devfs deadlock fix
  o epoll-per-fd fix

Andries E. Brouwer:
  o cryptoloop

Bernardo Innocenti:
  o asm-generic/div64.h breakage

Brian Gerst:
  o c99 initializers for init/version.c

Daniel Ritz:
  o more net driver timer fixes
  o net/pcmcia fix fast_poll timers (HZ > 100)

Dave Jones:
  o [AGPGART] Remove unneeded assignment
  o [AGPGART] Use defines for register bits in AMD K8 GART driver
  o [AGPGART] K8 GART driver doesn't need masks
  o [AGPGART] Ignore multiple K8 GARTS on UP
  o [AGPGART] Optimise PCI searching in K8 GART driver
  o [AGPGART] K8 Device 0x1103 is always at PCI_FUNC 3
  o [AGPGART] K8 North bridge bus position is no longer relevant
  o [AGPGART] HP AGP update
  o [AGPGART] Sort SiS device IDs
  o [AGPGART] SiS 746 support This (and a few other SiS chipsets) are
    AGP 3 compliant. AFAIK, none of these have been tested in AGP3
    mode, but they should work just fine in AGP2.x mode at least.
  o [AGPGART] SiS 648 support
  o [AGPGART] Make frontend sparse clean

David Brownell:
  o USB: usb_get_string(), don't use bogus ids
  o USB: usbnet, don't NET_XMIT_DROP

David S. Miller:
  o [SPARC]: SEMTIMEDOP for both Sparc ports
  o [SPARC64]: Port over IPC msg{snd,rcv} compat32 fixes from ia64
  o [TCP]: When in SYN-SENT, initialize metrics after move to
    established state
  o [NET]: Ok, sunhme is VLAN challenged after all
  o [IPV6]: Build and send redirect packet using "buff" not "skb",
    fixes OOPS
  o [IPV6]: Fix dst reference counting in ndisc_send_redirect()
  o [NET,COMPAT]: Delete bogus icmpv6 filter translation code
  o [IPV6]: Fix leaks of ndisc DST entries
  o [SPARC64]: Ditch local KALLSYMS from Kconfig, update defconfig
  o [SPARC64]: Implement force_successful_syscall()
  o [SPARC64]: Use mm->free_area_cache
  o [IPV4]: Do not redefine config macros in net/ip_vs.h
  o [IPV4]: Always use Jenkins hash in ipvs conn table, use
    get_random_bytes() to init key
  o [IPV4]: Kill slow timers from IPVS, they are superfluous and
    inefficient these days

David Stevens:
  o [IPV4]: Do not sent IGMP leave messages unless IFF_UP

Dominik Brodowski:
  o [PCMCIA] don't hide calls to socket drivers
  o [PCMCIA] rename ss_entry to ops

François Romieu:
  o Fix AD1889 driver 2.4 merge
  o Fix error path in AD1889 driver

Greg Kroah-Hartman:
  o USB: fix up my USB Bluetooth entry to help prevent confusion in the
    future
  o USB: remove pointless warning about using usbdevfs

Herbert Xu:
  o [IPSEC]: Missing reqid check in xfrm_state_ok

Hideaki Yoshifuji:
  o [IPV6]: Fix offset of payload with extension header

Ian Abbott:
  o USB: ftdi_sio update

James Morris:
  o [NETLINK]: Just drop packets for kernel netlink socket with no
    data_ready handler

Jean Tourrilhes:
  o [IrDA] include cleanup
  o [IrDA] struct check
  o [IrDA] irtty leaks
  o [IrDA] irnet cast
  o [IrDA] IrCOMM devfs
  o [IrDA] setup dma fix
  o [IrDA] irda-usb endian
  o [IrDA] nsc 39x support

Jeff Garzik:
  o [netdrvr tg3] more ULL suffixes to make gcc 3.3 happy
  o [netdrvr] fix compiler warnings in 3c359, proteon, skisa tokenring
    drivers.
  o [netdrvr wavelan] remove check_region usage
  o [netdrvr atmel_cs] kill compiler warning (jumping to "empty" label)

Jens Axboe:
  o disk stats accounting fix
  o Fix IDE-CD command failure re-play
  o fs accounting, part 2

Kay Sievers:
  o usblp: usb_buffer_free() not called Here is the blind flight :-)
    === drivers/usb/class/usblp.c usblp->dev was set to NULL to
    indicate a device disconnect but we need this value for
    usb_buffer_free() when device is still opened and cleanup is
    delayed until usblp_release().

Linus Torvalds:
  o Avoid mmap() overflow case if TASK_SIZE is the full range of an
    "unsigned long" (sparc64).
  o Merge comment updates from DRI CVS tree
  o Update i810 DRI driver from CVS to add page flipping
  o Update r128 driver from DRI CVS: add support for ycbcr textures
  o Update radeon driver from DRI CVS: add more commands
  o Merge from DRI CVS tree: avoid zero DRI "handles"
  o Merge with DRI CVS tree - which added a reminder to the DRI people
    not to remove the HAVE_KERNEL_CTX_SWITCH support that the sparc
    drivers require.
  o Fix signedness tests in vsnprintf by making it explicit
  o Mark Bartlomiej as the IDE maintainer, about 3 months late ;)
  o Disable TI cardbus PCI IRQ routing code that was forward-ported
    from 2.4-ac - it seems to cause hangs for people.

Matthew Dharm:
  o USB: fix usb-storage initializers
  o USB: fix datafab and freecom to use I/O buffer

Matthew Wilcox:
  o parisc updates
  o Makefile update for parisc
  o eisa Kconfig update for parisc
  o Add two sysctls for PA-RISC
  o Remove warning from binfmt_elf.c for upwards growing stack
  o gsc-ps2 update

Miles Bader:
  o Use <asm-generic/statsfs.h> on v850
  o More irqreturn_t changes for v850
  o show_stack changes for v850

Nivedita Singhvi:
  o [NET]: Fix typo in net-sysfs.c copyright

Pete Zaitcev:
  o [SPARC]: Clean secondary System.map
  o [SPARC]: defconfig for willy's scsi
  o [SPARC]: hch's cond_syscall() for PCI syscalls, Alpha/PPC/etc. can
    use this too
  o [SPARC]: Redo show_stack()
  o [SPARC]: Trap table alignment for Hyperspace (Keith Weselowsky)

Petr Sebor:
  o via-agp.c - agp_try_unsupported typo

Petr Vandrovec:
  o new sysctl checking accesses userspace directly

Ralf Bächle:
  o mkiss

Richard Henderson:
  o [ALPHA] Add tgkill syscall
  o [ALPHA] Set correct CLOCK_TICK_RATE for the RTC
  o [ALPHA] Remove SBUS & MCA from alpha Kconfig

Robert Zwerus:
  o Documentation/CodingStyle spelling fixes

Russell King:
  o [PCMCIA] Prevent PCMCIA oops during socket driver initialisation
  o [PCMCIA] Fix hangs when PCMCIA modules loaded

Samuel Thibault:
  o [2.5] maestro volume tuning

Stephen Hemminger:
  o convert plip to alloc_netdev
  o [netdrvr dgrs] convert to using alloc_etherdev

Steve French:
  o NTLMv2 password support and NTLMSSP signing part 1
  o ntlmssp signing
  o More NTLMv2
  o Open / Create lookup intents part one
  o Add mknod support
  o fix cifs distributed caching - send oplock release immediately
    after flush of writebehind data on oplock break from server

Thomas Graf:
  o [NET]: Return EDESTADDRREQ as appropriate in sendmsg
    implementations

Ulrich Drepper:
  o Re: utimes/futimes/lutimes syscalls

Wensong Zhang:
  o [NET]: Merge in IPVS layer

Re: Linux v2.6.0-test1

[Matt Reppert]

I need this to build on powerpc (plus the patch by Jasper Spaans already posted).

Matt

diff -NruX /home/arashi/kdontdiff linux-2.6.0-test1-orig/drivers/cpufreq/proc_intf.c linux-2.6.0-test1/drivers/cpufreq/proc_intf.c
--- linux-2.6.0-test1-orig/drivers/cpufreq/proc_intf.c  2003-07-13 23:30:48.000000000 -0400
+++ linux-2.6.0-test1/drivers/cpufreq/proc_intf.c       2003-07-14 23:41:49.000000000 -0400
@@ -13,7 +13,6 @@
 #include <asm/uaccess.h>


-#define CPUFREQ_ALL_CPUS               ((NR_CPUS))

 /**
  * cpufreq_parse_policy - parse a policy string
diff -NruX /home/arashi/kdontdiff linux-2.6.0-test1-orig/include/linux/notifier.h linux-2.6.0-test1/include/linux/notifier.h
--- linux-2.6.0-test1-orig/include/linux/notifier.h     2003-07-13 23:30:36.000000000 -0400
+++ linux-2.6.0-test1/include/linux/notifier.h  2003-07-14 23:41:56.000000000 -0400
@@ -65,6 +65,7 @@
 #define CPU_UP_CANCELED        0x0004 /* CPU (unsigned)v NOT coming up */
 #define CPU_OFFLINE    0x0005 /* CPU (unsigned)v offline (still scheduling) */
 #define CPU_DEAD       0x0006 /* CPU (unsigned)v dead */
+#define CPUFREQ_ALL_CPUS               ((NR_CPUS))

 #endif /* __KERNEL__ */
 #endif /* _LINUX_NOTIFIER_H */

Re: Linux v2.6.0-test1

[Dave Jones]

On Tue, Jul 15, 2003 at 12:11:32AM -0400, Matt Reppert wrote:
 > I need this to build on powerpc (plus the patch by Jasper Spaans already posted).

 >   * cpufreq_parse_policy - parse a policy string
 > diff -NruX /home/arashi/kdontdiff linux-2.6.0-test1-orig/include/linux/notifier.h linux-2.6.0-test1/include/linux/notifier.h
 > --- linux-2.6.0-test1-orig/include/linux/notifier.h     2003-07-13 23:30:36.000000000 -0400
 > +++ linux-2.6.0-test1/include/linux/notifier.h  2003-07-14 23:41:56.000000000 -0400
 > @@ -65,6 +65,7 @@
 >  #define CPU_UP_CANCELED        0x0004 /* CPU (unsigned)v NOT coming up */
 >  #define CPU_OFFLINE    0x0005 /* CPU (unsigned)v offline (still scheduling) */
 >  #define CPU_DEAD       0x0006 /* CPU (unsigned)v dead */
 > +#define CPUFREQ_ALL_CPUS               ((NR_CPUS))
 > 
 >  #endif /* __KERNEL__ */
 >  #endif /* _LINUX_NOTIFIER_H */

include/linux/cpufreq.h seems a more natural place to put this.
Can you confirm that works ok on PPC? I lack hardware to test.

Otherwise, looks good.

		Dave

Re: Linux v2.6.0-test1

[Dominik Brodowski]

On Tue, Jul 15, 2003 at 11:56:57AM +0100, Dave Jones wrote:
> On Tue, Jul 15, 2003 at 12:11:32AM -0400, Matt Reppert wrote:
>  > I need this to build on powerpc (plus the patch by Jasper Spaans already posted).
> 
>  >   * cpufreq_parse_policy - parse a policy string
>  > diff -NruX /home/arashi/kdontdiff linux-2.6.0-test1-orig/include/linux/notifier.h linux-2.6.0-test1/include/linux/notifier.h
>  > --- linux-2.6.0-test1-orig/include/linux/notifier.h     2003-07-13 23:30:36.000000000 -0400
>  > +++ linux-2.6.0-test1/include/linux/notifier.h  2003-07-14 23:41:56.000000000 -0400
>  > @@ -65,6 +65,7 @@
>  >  #define CPU_UP_CANCELED        0x0004 /* CPU (unsigned)v NOT coming up */
>  >  #define CPU_OFFLINE    0x0005 /* CPU (unsigned)v offline (still scheduling) */
>  >  #define CPU_DEAD       0x0006 /* CPU (unsigned)v dead */
>  > +#define CPUFREQ_ALL_CPUS               ((NR_CPUS))
>  > 
>  >  #endif /* __KERNEL__ */
>  >  #endif /* _LINUX_NOTIFIER_H */
> 
> include/linux/cpufreq.h seems a more natural place to put this.
> Can you confirm that works ok on PPC? I lack hardware to test.

No, please don't do this. There is no function at all in the cpufreq core 
which may be called with CPUFREQ_ALL_CPUS as arguments. Well, there had 
been, many months ago. But it really shall not be defined or used anywhere 
outside the 2.4. proc-intf any more.

Now, wrt the ppc-cpufreq driver: benh's 2.5. tree includes a much more
updated version than plain 2.6.0-test1 -- Ben, can you push that to Linus,
please? Also, please change the line 
 	freqs.cpu = CPUFREQ_ALL_CPUS;
in do_set_cpu_speed() to 
	freqs.cpu = 0;
which is the way it should be done now.

	Dominik

Re: Linux v2.6.0-test1

[Dave Jones]

On Tue, Jul 15, 2003 at 07:38:44PM +0200, Dominik Brodowski wrote:

 > No, please don't do this. There is no function at all in the cpufreq core 
 > which may be called with CPUFREQ_ALL_CPUS as arguments. Well, there had 
 > been, many months ago. But it really shall not be defined or used anywhere 
 > outside the 2.4. proc-intf any more.

ick, you're right of course.

 > Now, wrt the ppc-cpufreq driver: benh's 2.5. tree includes a much more
 > updated version than plain 2.6.0-test1 -- Ben, can you push that to Linus,
 > please? Also, please change the line 
 >  	freqs.cpu = CPUFREQ_ALL_CPUS;
 > in do_set_cpu_speed() to 
 > 	freqs.cpu = 0;
 > which is the way it should be done now.

Ok, CPUFREQ_ALL_CPUS is no more in my pending tree.
Documentation/cpu-freq/core.txt is also out of date and could use
an update, but I'm not sure if its just that define thats out of date.
Care to give it a read through? 

		Dave

Re: DMA gone on ALI 1533

[Peter]

I had included kernel support for the ALI 15X3 chipset, but as a module --
and it obviously didn't load. If I include the module in /etc/modules, it
loads too late (details below). I'm assuming this means "make menuconfig"
mistakenly provides the module option? I've recompiled it into the kernel
and got DMA back (although only dma2, as before) -- thanks for the quick
feedback!

Cheers,
Peter


Details on what happens when you compile ALI 15X3 as a module -- I'm 
guessing this should not be an option?

A. Should the module have loaded automatically? I had 

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

B. I then included the module in /etc/modules and got this in dmesg:
   
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 66MHz system bus speed for PIO modes
hda: IC25N040ATCS04-0, ATA DISK drive
hdc: MATSHITACD-RW CW-8121, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=77520/16/63
 
-- that is to say, no change in first pass detection. Then this:

ALI15X3: IDE controller at PCI slot 00:10.0
ACPI: No IRQ known for interrupt pin A of device 00:10.0
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:pio, hdd:pio
ide0: I/O resource 0x1F0-0x1F0 not free.

I guess it was too late. 

So no performance improvement:
# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.46 seconds =275.90 MB/sec
 Timing buffered disk reads:  64 MB in 19.69 seconds =  3.25 MB/sec

lsmod:
alim15x3                7052  1 [unsafe]

Linux v2.6.0-test1

[Peter]

The kernel compiled with no errors. On booting, I got this:

ACPI: Subsystem revision 20030619
ACPI breakpoint: Executed AML Breakpoint opcode

If I just wanted to boot, which option should I disable?

This is a vpr matrix 200a5 laptop with an ALi M1671 chipset and various 
ACPI options enabled, including CONFIG_X86_P4_CLOCKMOD=m. Details below.

2.5.69 has been running fine for a long time now, but there are some new 
ACPI options. 

Cheers,
Peter


System:

00:00.0 Host bridge: ALi Corporation M1671 Super P4 Northbridge [AGP4X,PCI and SDR/DDR] (rev 02)
00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)
00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV]
00:09.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan chipset (rev 01)
00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
00:0b.0 USB Controller: VIA Technologies, Inc. USB (rev 50)
00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
00:11.0 Bridge: ALi Corporation M7101 PMU
00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3)


Configuration:

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y

#
# ACPI Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_HT_ONLY is not set
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set
CONFIG_CPU_FREQ_TABLE=y

#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set