Linux 2.6.22 released

Linus Torvalds

unread,

Jul 8, 2007, 7:53:27 PM7/8/07

to Linux Kernel Mailing List

It's out there now (or at least in the process of mirroring out - if you
don't see everything, give it a bit of time).

Not a whole lot of changes since -rc7: some small architecture changes
(ppc, mips, blackfin), and most of those are defconfig updates. Various
driver fixes: new PCI ID's along with some ide, ata and networking fixes
(for example - the magic wireless libertas ioctl's got removed, they may
be re-added later, hopefully in a more generic form, but in the meantime
this doesn't make a release with new interfaces that aren't universally
liked).

And various random fixes for regressions and other buglets. Mostly really
small "few-liners"..

The shortlog (appended) is fairly self-explanatory and the diffstat (at
the very end) also gives a fairly good picture of where the changes are.

The full changelog since 2.6.21 also got uploaded, but quite frankly, I
wonder if anybody uses those things? I've been uploading them for non-git
users, but I have a suspicion that any people who want that kind of
detail have long since learnt to use git, or are following the commit
mailing lists or equivalent.

So this is also a heads-up that I'm considering skipping the ChangeLog
files in the future - the full release ones are so big as to not be very
easily readable (the full ChangeLog from 2.6.21 is ove ra hundred thousand
lines, and weighs in at 3.8MB for example), and you really can get much
better per-subsystem logs from git.

Anybody? Should I make just the shortlogs available instead (I don't save
those, but I post those for the later -rc's - usually the -rc1 and -rc2's
are too big for the mailing list, but they are still a lot smaller and
more readable than the *full* logs are)?

Or do people really want the full logs, and don't use git?

Let me know how you feel. And test the actual release out too, of course!

Linus

---
Adrian Bunk (4):
drivers/net/ns83820.c: fix a check-after-use
[NET]: net/core/netevent.c should #include <net/netevent.h>
include/linux/kallsyms.h must #include <linux/errno.h>
DLM must depend on SYSFS

Alan Cox (4):
ata_generic: Check the right register for the DMA enabled flags
pata_pdc202xx_old: Correct cable detect logic
pata_pcmcia: Switch to ata_sff_port_start
ide: Fix a theoretical Ooops case

Albert Lee (3):
libata: pata_pdc2027x PLL input clock fix
libata: remove reading alt_status from ata_hsm_qc_complete()
ide: pdc202xx_new PLL input clock fix

Alexander Graf (1):
fix logic error in ipc compat semctl()

Andi Kleen (2):
Revert HPET resource reservation
Revert perfctr reservation to 2.6.21 state

Andres Salomon (1):
GEODE: reboot fixup for geode machines with CS5536 boards

Andrew Morton (1):
ide: ide_scan_pcibus(): check __pci_register_driver return value

Andrew Sharp (1):
[MIPS] 64-bit TO_PHYS_MASK macro for RM9000 processors

Andrzej Zaborowski (1):
[ARM] 4454/1: Use word accesses in Versatile PCI config reads

Atsushi Nemoto (1):
[MIPS] Add whitelists for checksyscalls.sh

Bartlomiej Zolnierkiewicz (3):
amd74xx: resume fix
it821x: fix incorrect SWDMA mask
qd65xx: fix PIO mode selection

Bjorn Helgaas (1):
PNP SMCf010 quirk: work around Toshiba Portege 4000 ACPI issues

Chris Dearman (1):
[MIPS] Fix timer/performance interrupt detection

Christian Krafft (1):
[POWERPC] Fix PMI breakage in cbe_cbufreq driver

Christoph Lameter (2):
SLUB: Make lockdep happy by not calling add_partial with interrupts enabled during bootstrap
slub: remove useless EXPORT_SYMBOL

Chuck Ebbert (1):
pata_ali: fix UDMA settings

Dan Williams (4):
libertas: style fixes
libertas: kill wlan_scan_process_results
libertas: fix WPA associations by handling ENABLE_RSN correctly
libertas: remove private ioctls

Dave Jones (1):
Clean up E7520/7320/7525 quirk printk.

David Brownell (1):
net/usb/cdc_ether minor sparse cleanup

David Gibson (1):
[POWERPC] Disable old EMAC driver in arch/powerpc

David Woodhouse (4):
[JFFS2] Fix readinode failure when read_dnode() detects CRC failure.
Fix slab redzone alignment
x86_64: fix headers_install
Fix use-after-free oops in Bluetooth HID.

Dhananjay Phadke (1):
RESEND [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload

Dmitry Torokhov (4):
Input: i8042 - add HP Pavilion ZT1000 to the MUX blacklist
Input: atkbd - throttle LED switching
Input: serio - take drv_mutex in serio_cleanup()
Input: document some of keycodes

Florian Attenberger (1):
sata_mv: PCI-ID for Adaptec 1430SA SATA Controller

Hartmut Birr (1):
V4L/DVB (5822): Fix the return value in ttpci_budget_init()

Henrique de Moraes Holschuh (1):
Input: add a new EV_SW SW_RADIO event, for radio switches on laptops

Jack Morgenstein (1):
mlx4_core: Add new Mellanox device IDs

Jarek Poplawski (1):
[NETPOLL]: Fixups for 'fix soft lockup when removing module'

Jason Wessel (1):
i386: fix regression, endless loop in ptrace singlestep over an int80

Jeff Garzik (1):
[libata] sata_nv: undo merge error

Jelle Foks (1):
V4L/DVB (5816): Cx88-blackbird: fix vidioc_g_tuner never ending list of tuners

Jie Zhang (1):
Blackfin arch: Add proper -mcpu option according to the cpu and silicon revision configuration

Jing Min Zhao (1):
[NETFILTER]: nf_conntrack_h323: add checking of out-of-range on choices' index values

Johannes Berg (1):
[NET] skbuff: remove export of static symbol

Kumar Gala (2):
gianfar: Fix typo bug introduced by move to udp_hdr()
[POWERPC] Update defconfigs

Kumba (1):
[MIPS] Fix include wrapper symbol definitions in IP32 code.

Len Brown (1):
ACPI: fix acpi_osi=!Linux

Linus Torvalds (4):
Remove some unused variables
Remove the blink driver
Fix permission checking for the new utimensat() system call
Linux 2.6.22

Loic Prylli (1):
MTRR: Fix race causing set_mtrr to go into infinite loop

Maciej W. Rozycki (1):
[MIPS] die(): Properly declare as non-returning

Maik Hampel (1):
myri10ge: SET_NETDEV_DEV()

Marco Roeland (1):
Blackfin arch: remove zero-sized include/asm-blackfin/macros.h

Masatake YAMATO (1):
ide: never called printk statement in ide-taskfile.c::wait_drive_not_busy

Michael Ellerman (1):
Fix elf_core_dump() when writing arch specific notes (spu coredumps)

Mike Frysinger (1):
Blackfin arch: update board defconfig files

Oleg Nesterov (1):
V4L/DVB (5818): CinergyT2: fix flush_workqueue() vs work->func() deadlock

Olof Johansson (1):
[POWERPC] Uninline and export virq_to_hw() for the pasemi_mac driver

Patrick McHardy (1):
3c589_cs: fix local_bh_enable warning

Peter Korsgaard (4):
dm9601: HW header size shouldn't be included in packet length
usbnet: Zero padding byte if there is tail room in skb
Update MAINTAINERS for USB network devices
dm9601: Return 0 from bind() on success

Peter Zijlstra (2):
mm: fixup /proc/vmstat output
mm: double mark_page_accessed() in read_cache_page_async()

Qi Yong (1):
Input: atkbd - use printk_ratelimit for spurious ACK messages

Ralf Baechle (7):
[MIPS] VSMP: Fix initialization ordering bug.
[MIPS] AP/SP: Avoid triggering the 34K E125 performance issue
[MIPS] Change libgcc-style functions from lib-y to obj-y
[MIPS] SMTC: Fix cut'n'paste bug in Kconfig.debug
[MIPS] RM7000: Enable ICACHE_REFILLS_WORKAROUND_WAR.
[MIPS] Add macros to encode processor revisions.
[MIPS] Fix scheduling latency issue on 24K, 34K and 74K cores

Ralph Campbell (1):
IPoIB/cm: Partial error clean up unmaps wrong address

Randy Dunlap (1):
scsi disk help file is not complete

Richard Purdie (1):
[ARM] 4458/1: pxa: Fix CKEN usage and hence fix pxa suspend/resume

Robert Hancock (1):
sata_nv: allow changing queue depth

Robin Getz (1):
Blackfin arch: Fix up remaining printks with proper log levels

Russell King (2):
[ARM] Fix non-page aligned boot time mappings
[ARM] always allow dump_stack() to produce a backtrace

Sergei Shtylyov (2):
hpt366: blacklist MAXTOR STM3320620A for UltraDMA/66
hpt366: use correct enablebits for HPT36x

Stefan Richter (2):
firewire: fix async reception on big endian machines
firewire: add Kconfig help on building both stacks

Tejun Heo (3):
sata_inic162x: disable LBA48 devices
libata: add HTS541616J9SA00 to NCQ blacklist
libata: fix assigned IRQ reporting

Thomas Gleixner (1):
NTP: remove clock_was_set() call to prevent deadlock

Trent Piepho (1):
V4L/DVB (5808): Bttv: fix v4l1 breaking the driver

Uwe Koziolek (2):
libata: PATA-mode fixes for sis_sata
sis5513: adding PCI-ID

Vivek Goyal (1):
i386: es7000 build breakage fix

Vlad Yasevich (3):
SCTP: Fix thinko in sctp_copy_laddrs()
SCTP: Check to make sure file is valid before setting timeout
SCTP: Add scope_id validation for link-local binds

Yoann Padioleau (1):
potential compiler error, irqfunc caller sites update

Zach Brown (1):
dio: remove bogus refcounting BUG_ON

dhananja...@gmail.com (2):
RESEND [PATCH 1/3] NetXen: Fix issue of MSI not working correctly
RESEND [PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers

maximilian attems (2):
starfire list alpha as 64 bit arch
MAINTAINERS new kernel janitors ml

Jesper Juhl

unread,

Jul 8, 2007, 8:19:46 PM7/8/07

to Linus Torvalds, Linux Kernel Mailing List

On 09/07/07, Linus Torvalds <torv...@linux-foundation.org> wrote:
[snip]

> The shortlog (appended) is fairly self-explanatory and the diffstat (at
> the very end) also gives a fairly good picture of where the changes are.
>

I've always felt that these "shortlog since last -rc for a full
release" were a bit pointless.
Whoever is reading the release notes for a final 2.6.x release is not
going to be really interrested in what changed since the last -rc,
they want to know what changed since the last 2.6.(x-1) kernel. And
the people who are interrested in the changes since last -rc have
obviously been keeping track of what happened between the previous
-rc's (or else reading the last one doesn't make much sense).

> The full changelog since 2.6.21 also got uploaded, but quite frankly, I
> wonder if anybody uses those things? I've been uploading them for non-git
> users, but I have a suspicion that any people who want that kind of
> detail have long since learnt to use git, or are following the commit
> mailing lists or equivalent.
>

I believe you are right, but it's still a nice thing to have for
archeology purposes. To be able to download kernel 2.6.(some old x)
along with its Changelog makes for a nice combined package where
people can see where this kernel is different from the previous one...
it's just a nice thing to have in the FTP archives.
I won't cry much if it dies, but on the other hand I think it's a good
thing to have archived in a plain-text form for posterity.

> So this is also a heads-up that I'm considering skipping the ChangeLog
> files in the future - the full release ones are so big as to not be very
> easily readable (the full ChangeLog from 2.6.21 is ove ra hundred thousand
> lines, and weighs in at 3.8MB for example), and you really can get much
> better per-subsystem logs from git.
>
> Anybody? Should I make just the shortlogs available instead (I don't save
> those, but I post those for the later -rc's - usually the -rc1 and -rc2's
> are too big for the mailing list, but they are still a lot smaller and
> more readable than the *full* logs are)?
>

This is just my oppinion. The shortlogs are nice and readable,
archiving the shortlog-between-rc's would be nice, as for the full
logs see above.

I think what would be even better than posting full-/short-logs after
each -rc/full release, would be to post a list of who was involved in
that specific kernel release. I think that you are right that the
people who want the full details know how to use git (or else they can
get to parse the full Changelog), but what's really more interresting
is giving credit where it is due.
I'd suggest that whenever you release a new kernel you should upload
the full Changelog since last version, just so it's available. But, in
your release notes you should just list who contributed to that new
release, something like this :

juhl@dragon:~/kernel/linux-2.6$ git log v2.6.21..v2.6.22 | egrep
"^Author: " | sort | uniq -c | sort -n -r
283 Author: Linus Torvalds <torv...@woody.linux-foundation.org>
174 Author: David S. Miller <da...@sunset.davemloft.net>
106 Author: Kristian Høgsberg <k...@redhat.com>
88 Author: Stephen Hemminger <shemm...@linux-foundation.org>
84 Author: Christoph Lameter <clam...@sgi.com>
82 Author: Stefan Richter <ste...@s5r6.in-berlin.de>
79 Author: Arnaldo Carvalho de Melo <ac...@redhat.com>
78 Author: Tejun Heo <hte...@gmail.com>
78 Author: Patrick McHardy <ka...@trash.net>
78 Author: Dmitry Torokhov <dt...@insightbb.com>
..

The details are in git / the Changelog, but this lets the worls easily
see who contributed - I suspect that's a lot more interresting to the
people reading your release-mails. I could be wrong (and I probably
am) ;-)

> Or do people really want the full logs, and don't use git?
>

git rules. It's a fantastic tool - anyone wanting the full details
should use it.

> Let me know how you feel. And test the actual release out too, of course!
>

Running 2.6.22-rc7-g4e99325b atm :)

--
Jesper Juhl <jespe...@gmail.com>

Phil Oester

unread,

Jul 8, 2007, 9:15:41 PM7/8/07

to Linus Torvalds, Linux Kernel Mailing List

On Sun, Jul 08, 2007 at 04:52:52PM -0700, Linus Torvalds wrote:
> Anybody? Should I make just the shortlogs available instead (I don't save
> those, but I post those for the later -rc's - usually the -rc1 and -rc2's
> are too big for the mailing list, but they are still a lot smaller and
> more readable than the *full* logs are)?
>
> Or do people really want the full logs, and don't use git?

I don't use git, and sometimes find it useful to view the changelogs to look
for when a particular change occurred. Doing so via:

http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.X

where X is decremented from current rev is handy. Please keep them around.

Phil

Willy Tarreau

unread,

Jul 9, 2007, 1:01:24 AM7/9/07

to Linus Torvalds, Linux Kernel Mailing List

On Sun, Jul 08, 2007 at 04:52:52PM -0700, Linus Torvalds wrote:

> Anybody? Should I make just the shortlogs available instead (I don't save
> those, but I post those for the later -rc's - usually the -rc1 and -rc2's
> are too big for the mailing list, but they are still a lot smaller and
> more readable than the *full* logs are)?
>
> Or do people really want the full logs, and don't use git?

The changelogs would be more useful if they were indexed by google, but
it seems they aren't (maybe too big, since 2.4 and 2.6.16 changelogs are
indexed ?). At least having the shortlog available would be a minimum,
provided that we try to keep the most possible descriptive subjects.
This also means being more transparent about security fixes.

Willy

Jan De Luyck

unread,

Jul 9, 2007, 2:08:00 AM7/9/07

to linux-...@vger.kernel.org

On Monday 09 July 2007, Phil Oester wrote:
> On Sun, Jul 08, 2007 at 04:52:52PM -0700, Linus Torvalds wrote:
> > Anybody? Should I make just the shortlogs available instead (I don't save
> > those, but I post those for the later -rc's - usually the -rc1 and -rc2's
> > are too big for the mailing list, but they are still a lot smaller and
> > more readable than the *full* logs are)?
> >
> > Or do people really want the full logs, and don't use git?
>
> I don't use git, and sometimes find it useful to view the changelogs to
> look for when a particular change occurred. Doing so via:
>
> http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.X
>
> where X is decremented from current rev is handy. Please keep them around.

I second this. The shortlog from rcX to -final is not really useful for me.

Jan

--
You'll be called to a post requiring ability in handling groups of people.

Alan Cox

unread,

Jul 9, 2007, 6:08:54 AM7/9/07

to Linus Torvalds, Linux Kernel Mailing List

Are the shortlogs useful - yes .. they catch what appear to be mistakes

Specifically: What happened to the aacraid ioctl security fix ? Did someone decide it
wasn't needed or did it get lost somewhere on the way ?

While this looks scary the only obvious exploit cases are where the user can
open a device level file on an AACraid. Very few people put scanners or CD
devices on one so the actual impact is probably minimal.

Alan

--

Signed-off-by: Alan Cox <al...@redhat.com>

--- drivers/scsi/aacraid/linit.c~ 2007-07-09 10:51:55.653223304 +0100
+++ drivers/scsi/aacraid/linit.c 2007-07-09 10:51:55.653223304 +0100
@@ -453,6 +453,8 @@
static int aac_ioctl(struct scsi_device *sdev, int cmd, void __user * arg)
{
struct aac_dev *dev = (struct aac_dev *)sdev->host->hostdata;
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
return aac_do_ioctl(dev, cmd, arg);
}

@@ -645,6 +647,8 @@
static int aac_compat_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
{
struct aac_dev *dev = (struct aac_dev *)sdev->host->hostdata;
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
return aac_compat_do_ioctl(dev, cmd, (unsigned long)arg);

Jan Engelhardt

unread,

Jul 9, 2007, 6:30:46 AM7/9/07

to Linus Torvalds, Linux Kernel Mailing List

Hi,

On Jul 8 2007 16:52, Linus Torvalds wrote:
>
>So this is also a heads-up that I'm considering skipping the ChangeLog
>files in the future - the full release ones are so big as to not be very
>easily readable (the full ChangeLog from 2.6.21 is ove ra hundred thousand
>lines, and weighs in at 3.8MB for example), and you really can get much
>better per-subsystem logs from git.
>
>Anybody? Should I make just the shortlogs available instead (I don't save
>those, but I post those for the later -rc's - usually the -rc1 and -rc2's
>are too big for the mailing list, but they are still a lot smaller and
>more readable than the *full* logs are)?
>
>Or do people really want the full logs, and don't use git?
>
>Let me know how you feel. And test the actual release out too, of course!

The rc-to-rc shortlog is usually helpful. That way, I can see whether a
particular fix that I am interested in/involved with has already been
merged - or not and its needs some reminder. And the 2.6.x -> 2.6.y-rc1
shortlog for seeing whether patches, should I have decided to send
anything, actually went in. All other logs can be omitted from the mail
announcements. I still prefer to have all logs, as usual, both short
and long, via http (perhaps compressed for your pleasure), because
cloning a git is not always possible (think of public terminals) or
feasible (cloning does take a while, and longer on slower links).

Jan
--

Jan Engelhardt

unread,

Jul 9, 2007, 7:48:32 AM7/9/07

to Linus Torvalds, Linux Kernel Mailing List

On Jul 9 2007 12:30, Jan Engelhardt wrote:
>
>The rc-to-rc shortlog is usually helpful. That way, I can see whether a
>particular fix that I am interested in/involved with has already been
>merged - or not and its needs some reminder. And the 2.6.x -> 2.6.y-rc1
>shortlog for seeing whether patches, should I have decided to send
>anything, actually went in. All other logs can be omitted from the mail
>announcements.

Oh and these I can retrieve using git. :)
Which leaves..

>I still prefer to have all logs, as usual, both short
>and long, via http (perhaps compressed for your pleasure), because
>cloning a git is not always possible (think of public terminals) or
>feasible (cloning does take a while, and longer on slower links).

thanks,

Michal Piotrowski

unread,

Jul 9, 2007, 10:26:21 AM7/9/07

to Linux Kernel Mailing List

Hi all,

I'm looking for a volunteer who is willing to maintain the list of
known regressions in 2.6.22
http://kernelnewbies.org/known_regressions_2622

Anyone interested?

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/

Stefano Rivoir

unread,

Jul 10, 2007, 3:45:54 AM7/10/07

to Linus Torvalds, Linux Kernel Mailing List

Linus Torvalds wrote:
> It's out there now (or at least in the process of mirroring out - if you
> don't see everything, give it a bit of time).

Hi all.

2.6.22 hangs at boot on my box. Here attached a original dmesg from
2.6.21, and a copy of it where it stops on 2.6.22 (I can't attach the
original 2.6.22 dmesg because it's not logged to disk yet); it actually
stops right after 'init' launches.

Thinking it was something related to USB mass storage, I've disabled
(not in the attached .config) it but with no results.

Bye.

--
Stefano RIVOIR

config-2.6.22

dmesg-2.6.21

dmesg-2.6.22

lspcivv

Andrew Morton

unread,

Jul 10, 2007, 4:52:52 AM7/10/07

to Stefano Rivoir, Linus Torvalds, Linux Kernel Mailing List

If you have another Linux box on the LAN, please set up netconsole
(Documentation/networking/netconsole.txt) to gather the boot logs.

When the machine has stalled, see if you can get a task trace with
ALT-SYSRQ-t. This will require CONFIG_MAGIC_SYSRQ=y and possibly setting
ignore_loglevel on the kernel boot command line.

Thanks.

(mad guesses: try the following on the boot command line: clock=pit,
noacpi, noapic)

Linus Torvalds

unread,

Jul 10, 2007, 11:39:56 AM7/10/07

to Stefano Rivoir, Linux Kernel Mailing List

On Tue, 10 Jul 2007, Stefano Rivoir wrote:
>
> 2.6.22 hangs at boot on my box. Here attached a original dmesg from 2.6.21,
> and a copy of it where it stops on 2.6.22 (I can't attach the original 2.6.22
> dmesg because it's not logged to disk yet); it actually stops right after
> 'init' launches.

Ok, without any oops or hang in any really obvious place, that doesn't
really tell anybody anything specific enough to even start trying to debug
this, so you'd need to do one of two things:

- poke a lot at the machine to try to get more specific information. In
particular, get things like SysRQ-T output. That, in turn, probably
would mean trying to get a serial console hooked up or something.

The next thing that you got on 2.6.21 after the point it hangs was
apparently

..
input: PC Speaker as /class/input/input1
ieee1394: Initialized config rom entry `ip1394'
ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
ACPI: PCI Interrupt 0000:04:05.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19
usbcore: registered new interface driver hiddev
..

so you could _try_ to disable the PC speaker or firewire, and see
what's up. Did you switch from the old firewire drivers to the new one,
for example? Or if you didn't, try it.

IOW, we'd need a lot more debug information.

The second alternative will take some time, but is really a lot easier:

- Get a kernel git tree, and do a "git bisect".

There's almost 7000 commits in between 2.6.21 and 22, but that still
means that in about fourteen recompiles/reboots, "git bisect" should
tell us where your problem starts, which will hopefully make it obvious
what the problem is (or at least pinpoint it a *lot*).

Doing a git bisect isn't really that hard, but fourteen compiles/reboots
will take some time (well, the compiles will, the reboots aren't that
bad). But even if you're not a git user, it really is very simple:

- get started with 'git': on most distros it's now as simple as doing
something like

yum install git

and while you might not get the latest version (Debian stable is at
some ancient 1.4.4.4 version that isn't as nice as the 1.5.x series),
for something like this you won't care that deeply.

- get the kernel git tree (this will take a while to download about
180MB)

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

- start the "git bisect" with

git bisect good v2.6.21
git bisect bad v2.6.22

and it will pick a kernel version about half-way between the two
points, and you can now start testing. For each kernel you try, if it
boots fine, do "git bisect good", otherwise boot into a working kernel,
and then do "git bisect bad". Git will then pick the next "halfway"
kernel for that case.

Thanks,

Linus

Stefan Richter

unread,

Jul 10, 2007, 12:00:02 PM7/10/07

to Linus Torvalds, Stefano Rivoir, Linux Kernel Mailing List

Linus Torvalds wrote:
> On Tue, 10 Jul 2007, Stefano Rivoir wrote:
>> 2.6.22 hangs at boot on my box. Here attached a original dmesg from 2.6.21,
>> and a copy of it where it stops on 2.6.22

..

> The next thing that you got on 2.6.21 after the point it hangs was
> apparently
>
> ..
> input: PC Speaker as /class/input/input1
> ieee1394: Initialized config rom entry `ip1394'
> ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
> ACPI: PCI Interrupt 0000:04:05.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19
> usbcore: registered new interface driver hiddev
> ..
>
> so you could _try_ to disable the PC speaker or firewire, and see
> what's up. Did you switch from the old firewire drivers to the new one,
> for example?

His .config has the old 1394 drivers enabled and the new ones disabled.

> Or if you didn't, try it.

Or actually disable one driver or subsystem in each test boot. (Also
parport, USB...)
--
Stefan Richter
-=====-=-=== -=== -=-=-
http://arcgraph.de/sr/

Chuck Ebbert

unread,

Jul 10, 2007, 2:42:53 PM7/10/07

to Alan Cox, Linus Torvalds, Linux Kernel Mailing List, linux-scsi

On 07/09/2007 06:14 AM, Alan Cox wrote:
> Are the shortlogs useful - yes .. they catch what appear to be mistakes
>
> Specifically: What happened to the aacraid ioctl security fix ? Did someone decide it
> wasn't needed or did it get lost somewhere on the way ?
>
> While this looks scary the only obvious exploit cases are where the user can
> open a device level file on an AACraid. Very few people put scanners or CD
> devices on one so the actual impact is probably minimal.

I can't find that patch in any SCSI git tree.

> --- drivers/scsi/aacraid/linit.c~ 2007-07-09 10:51:55.653223304 +0100
> +++ drivers/scsi/aacraid/linit.c 2007-07-09 10:51:55.653223304 +0100
> @@ -453,6 +453,8 @@
> static int aac_ioctl(struct scsi_device *sdev, int cmd, void __user * arg)
> {
> struct aac_dev *dev = (struct aac_dev *)sdev->host->hostdata;
> + if (!capable(CAP_SYS_RAWIO))
> + return -EPERM;

-

Valdis.K...@vt.edu

unread,

Jul 10, 2007, 3:40:19 PM7/10/07

to Linus Torvalds, Linux Kernel Mailing List

On Sun, 08 Jul 2007 16:52:52 PDT, Linus Torvalds said:

> The full changelog since 2.6.21 also got uploaded, but quite frankly, I
> wonder if anybody uses those things? I've been uploading them for non-git
> users, but I have a suspicion that any people who want that kind of
> detail have long since learnt to use git, or are following the commit
> mailing lists or equivalent.

What the Rest Of The World could probably use is if some kind soul were to go
through and build a .21->.22 document that lists all the *userspace visible*
changes (new drivers, new filesystems/features, new/changed stuff in /sys and
/proc, new ioctls, new and changed Kconfig, etc). Unfortunately, it's quite
probably not automagically creatable, so we'd need to find another Adrian Bunk
to do it (BTW, between cleanups and keeping track of regressions and so on,
Adrian is definitely a resource we're lucky to have - let's have a round of
applause and appreciation for all of Adrian's work.. :)

> Or do people really want the full logs, and don't use git?

I'm not really a git user (I have enough trouble keeping a -mm tree around in
an unbusticated state) - but the few times I've needed info from git, I've
gotten it from the git-web interface. I think I've only looked at the
Changelogs once in the last 5 years, and it was because I was researching a
"When did feature XYZ go into the kernel?" for something that happened before
the bitkeeper and git days.

Adrian Bunk

unread,

Jul 10, 2007, 6:26:48 PM7/10/07

to Valdis.K...@vt.edu, Linus Torvalds, Linux Kernel Mailing List

On Tue, Jul 10, 2007 at 03:39:51PM -0400, Valdis.K...@vt.edu wrote:
> On Sun, 08 Jul 2007 16:52:52 PDT, Linus Torvalds said:
>
> > The full changelog since 2.6.21 also got uploaded, but quite frankly, I
> > wonder if anybody uses those things? I've been uploading them for non-git
> > users, but I have a suspicion that any people who want that kind of
> > detail have long since learnt to use git, or are following the commit
> > mailing lists or equivalent.
>
> What the Rest Of The World could probably use is if some kind soul were to go
> through and build a .21->.22 document that lists all the *userspace visible*
> changes (new drivers, new filesystems/features, new/changed stuff in /sys and
> /proc, new ioctls, new and changed Kconfig, etc).

>...

Already available:
http://kernelnewbies.org/Linux_2_6_22

Credits for it go to Diego Calleja.

It's a Wiki, so if you miss anything there you can add it yourself.

It might make sense if Linus would give a link to the corresponding
changelog there in future release announcements.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

Stefan Richter

unread,

Jul 10, 2007, 7:13:43 PM7/10/07

to Adrian Bunk, Valdis.K...@vt.edu, Linus Torvalds, Linux Kernel Mailing List

Adrian Bunk wrote:
> On Tue, Jul 10, 2007 at 03:39:51PM -0400, Valdis.K...@vt.edu wrote:
>> What the Rest Of The World could probably use is if some kind soul were to go
>> through and build a .21->.22 document that lists all the *userspace visible*
>> changes

> Already available:
> http://kernelnewbies.org/Linux_2_6_22

And of course there are several journalists who cover such matters.

I'm also sure that some subprojects issue their own release notes; e.g.
the linux1394 project does.
--
Stefan Richter
-=====-=-=== -=== -=-==
http://arcgraph.de/sr/

Adrian Bunk

unread,

Jul 10, 2007, 8:00:09 PM7/10/07

to Stefan Richter, Valdis.K...@vt.edu, Linus Torvalds, Linux Kernel Mailing List

On Wed, Jul 11, 2007 at 01:12:53AM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Tue, Jul 10, 2007 at 03:39:51PM -0400, Valdis.K...@vt.edu wrote:
> >> What the Rest Of The World could probably use is if some kind soul were to go
> >> through and build a .21->.22 document that lists all the *userspace visible*
> >> changes
>
> > Already available:
> > http://kernelnewbies.org/Linux_2_6_22
>
> And of course there are several journalists who cover such matters.

Most of them won't do deep research themselves, so offering one place
with much information isn't a bad thing.

> I'm also sure that some subprojects issue their own release notes; e.g.
> the linux1394 project does.

Don't expect other subsystem maintainers to be as good as you are. ;-)

But when you anyway publish release notes for your subsystem, also
pasting them to the Wiki shouldn't be much extra work.

> Stefan Richter

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-

da...@lang.hm

unread,

Jul 10, 2007, 8:06:57 PM7/10/07

to Adrian Bunk, Valdis.K...@vt.edu, Linus Torvalds, Linux Kernel Mailing List

On Wed, 11 Jul 2007, Adrian Bunk wrote:

> On Tue, Jul 10, 2007 at 03:39:51PM -0400, Valdis.K...@vt.edu wrote:
>> On Sun, 08 Jul 2007 16:52:52 PDT, Linus Torvalds said:
>>
>>> The full changelog since 2.6.21 also got uploaded, but quite frankly, I
>>> wonder if anybody uses those things? I've been uploading them for non-git
>>> users, but I have a suspicion that any people who want that kind of
>>> detail have long since learnt to use git, or are following the commit
>>> mailing lists or equivalent.
>>
>> What the Rest Of The World could probably use is if some kind soul were to go
>> through and build a .21->.22 document that lists all the *userspace visible*
>> changes (new drivers, new filesystems/features, new/changed stuff in /sys and
>> /proc, new ioctls, new and changed Kconfig, etc).
>> ...
>
> Already available:
> http://kernelnewbies.org/Linux_2_6_22
>
> Credits for it go to Diego Calleja.
>
> It's a Wiki, so if you miss anything there you can add it yourself.
>
> It might make sense if Linus would give a link to the corresponding
> changelog there in future release announcements.

lwn.net has a series on the API changes, they don't try to cover all the
drivers, but they should cover all the things that a driver writer would
need to worry about

http://lwn.net/Kernel/

David Lang

Valdis.K...@vt.edu

unread,

Jul 10, 2007, 8:33:45 PM7/10/07

to Stefan Richter, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List

On Wed, 11 Jul 2007 01:12:53 +0200, Stefan Richter said:
> Adrian Bunk wrote:
> > On Tue, Jul 10, 2007 at 03:39:51PM -0400, Valdis.K...@vt.edu wrote:
> >> What the Rest Of The World could probably use is if some kind soul were to go
> >> through and build a .21->.22 document that lists all the *userspace visible*
> >> changes
>
> > Already available:
> > http://kernelnewbies.org/Linux_2_6_22
>
> And of course there are several journalists who cover such matters.

Most journalists tend to do a very good 5-6 paragraphs about the *big* new
stuff - they'd probably quit after the first 20% (tops) of what Diego and
friends have done.

Definitely the resource I was looking for - thanks Diego and all.. :)

Stefano Rivoir

unread,

Jul 11, 2007, 2:38:50 AM7/11/07

to Linus Torvalds, Linux Kernel Mailing List

Linus Torvalds wrote:
>
> On Tue, 10 Jul 2007, Stefano Rivoir wrote:
>> 2.6.22 hangs at boot on my box. Here attached a original dmesg from 2.6.21,
>> and a copy of it where it stops on 2.6.22 (I can't attach the original 2.6.22
>> dmesg because it's not logged to disk yet); it actually stops right after
>> 'init' launches.
>
> Ok, without any oops or hang in any really obvious place, that doesn't
> really tell anybody anything specific enough to even start trying to debug
> this, so you'd need to do one of two things:

Hi,

Ok, the guilty bit is gcc: in my box, compiling kernel with gcc 4.2.x
(which is installed on my debian/sid) turns into a hang (in init,
seemingly, maybe not even in kernel itself), while gcc-4.1 is allright.

Probably it's something I had to know before... but the light lit when
gcc crashed when compiling 2.6.22-git1...

Bye.

--
Stefano RIVOIR

Linus Torvalds

unread,

Jul 11, 2007, 3:07:19 AM7/11/07

to Stefano Rivoir, Linux Kernel Mailing List

On Wed, 11 Jul 2007, Stefano Rivoir wrote:
>
> Ok, the guilty bit is gcc: in my box, compiling kernel with gcc 4.2.x (which
> is installed on my debian/sid) turns into a hang (in init, seemingly, maybe
> not even in kernel itself), while gcc-4.1 is allright.
>
> Probably it's something I had to know before... but the light lit when gcc
> crashed when compiling 2.6.22-git1...

Ok, I guess I should be happy, but gcc bugs end up being an absolute
*horror* to try to debug, and there is always a slight possibility that it
isn't a gcc bug, but some real kernel bug that is just hidden by the old
code generation. It happens occasionally.

The fact that gcc itself crashed when trying to compile something does
seem to indicate that it's one of those cases where it's unquestionably an
outright gcc bug, and we don't have to worry about some dodgy kernel code.
Which is a bit of a relief, but still, the gcc bug needs to be found,
preferably before that thing actually gets released.

I'm hoping your Debian/sid gcc version is some very experimental
known-buggy one, and not something that people _expect_ to be solid and
work well?

Linus

Stefan Richter

unread,

Jul 11, 2007, 6:58:34 AM7/11/07

to Adrian Bunk, Valdis.K...@vt.edu, Linus Torvalds, Linux Kernel Mailing List

Adrian Bunk wrote:
>> > http://kernelnewbies.org/Linux_2_6_22

> But when you anyway publish release notes for your subsystem, also
> pasting them to the Wiki shouldn't be much extra work.

I will do so from now on. Until now I was too lazy to create an account
there.

--
Stefan Richter
-=====-=-=== -=== -=-==
http://arcgraph.de/sr/

Stephen Frost

unread,

Jul 11, 2007, 7:06:45 AM7/11/07

to Linus Torvalds, Stefano Rivoir, Linux Kernel Mailing List

* Linus Torvalds (torv...@linux-foundation.org) wrote:
> I'm hoping your Debian/sid gcc version is some very experimental
> known-buggy one, and not something that people _expect_ to be solid and
> work well?

No such luck. :( Debian's close to moving to gcc-4.2 as the default
compiler in sid. We've rebuilt the archive a number of times (both
since the 4.2 release and during its development) using gcc-4.2 and
thought we'd identified most of the issues with it.

It clearly sounds like we need to open a high-severity bug on this issue
and track it down before we move to it as the default compiler. I'll
start harassing the appropriate folks also.

Stefano, can you file that bug, including the config, dmesg, and
backtrace from gcc if you can get it?

Thanks,

Stephen

signature.asc

Andi Kleen

unread,

Jul 11, 2007, 8:15:29 AM7/11/07

to Stefano Rivoir, Linus Torvalds, Linux Kernel Mailing List

Stefano Rivoir <s.ri...@gts.it> writes:

> Linus Torvalds wrote:
> > On Tue, 10 Jul 2007, Stefano Rivoir wrote:
> >> 2.6.22 hangs at boot on my box. Here attached a original dmesg from 2.6.21,
> >> and a copy of it where it stops on 2.6.22 (I can't attach the original 2.6.22
> >> dmesg because it's not logged to disk yet); it actually stops right after
> >> 'init' launches.
> > Ok, without any oops or hang in any really obvious place, that
> > doesn't really tell anybody anything specific enough to even start
> > trying to debug this, so you'd need to do one of two things:
>
> Hi,
>
> Ok, the guilty bit is gcc: in my box, compiling kernel with gcc 4.2.x
> (which is installed on my debian/sid) turns into a hang (in init,
> seemingly, maybe not even in kernel itself), while gcc-4.1 is allright.

The standard way to track this down is to compile different directories
of the kernel with different gcc versions. Then when you find the directory
go down to files. Then you could eventually go down to functions, although
that tends to involve quite some editing work. But already knowing
the file would be useful.

-Andi

Martin Orr

unread,

Jul 11, 2007, 8:46:11 AM7/11/07

to Stefano Rivoir, Linus Torvalds, Linux Kernel Mailing List

On 11/07/07 06:38, Stefano Rivoir wrote:
> Linus Torvalds wrote:
> > On Tue, 10 Jul 2007, Stefano Rivoir wrote:
> >> 2.6.22 hangs at boot on my box. Here attached a original dmesg from 2.6.21,
> >> and a copy of it where it stops on 2.6.22 (I can't attach the original 2.6.22
> >> dmesg because it's not logged to disk yet); it actually stops right after
> >> 'init' launches.

> Ok, the guilty bit is gcc: in my box, compiling kernel with gcc 4.2.x
> (which is installed on my debian/sid) turns into a hang (in init,
> seemingly, maybe not even in kernel itself), while gcc-4.1 is allright.

I have the same problem, also on Debian sid on amd64. I can report that the
Debian version 4.2-20070627-1 of gcc works, 4.2-20070707-1 does not.

Also the hang occurs in udevsettle; if you wait long enough (60 seconds?)
then udevsettle times out and the boot continues (but doesn't get very far
with an almost empty /dev).

For a few more data points, I tried building my kernel with the new compiler
and s/=m/=y/ on the .config and then disabling modules. This didn't help.
I have also tried mixing modules and vmlinuz from different gcc versions;
whether the hang occurs or not depends only on the version used to compile
the vmlinuz.

--
Martin Orr

signature.asc

Stefano Rivoir

unread,

Jul 11, 2007, 10:28:05 AM7/11/07

to Martin Orr, Linus Torvalds, Linux Kernel Mailing List

Martin Orr wrote:
> On 11/07/07 06:38, Stefano Rivoir wrote:
>> Linus Torvalds wrote:
>>> On Tue, 10 Jul 2007, Stefano Rivoir wrote:
>>>> 2.6.22 hangs at boot on my box. Here attached a original dmesg from 2.6.21,
>>>> and a copy of it where it stops on 2.6.22 (I can't attach the original 2.6.22
>>>> dmesg because it's not logged to disk yet); it actually stops right after
>>>> 'init' launches.
>> Ok, the guilty bit is gcc: in my box, compiling kernel with gcc 4.2.x
>> (which is installed on my debian/sid) turns into a hang (in init,
>> seemingly, maybe not even in kernel itself), while gcc-4.1 is allright.
>
> I have the same problem, also on Debian sid on amd64. I can report that the
> Debian version 4.2-20070627-1 of gcc works, 4.2-20070707-1 does not.
>
> Also the hang occurs in udevsettle; if you wait long enough (60 seconds?)
> then udevsettle times out and the boot continues (but doesn't get very far
> with an almost empty /dev).

I suspected it was something about /dev populating, but I hadn't any
clue on how to make it go on. To be sure, I've left it "hanging"
(actually, it's not a completely unresponsive hang, SysRq works fine)
for even 15 minutes, without any luck.

Could you please try to compile 2.6.22-git1 and see if you get an
internal gcc error? It is in the first kernel-core related files, you
should hit it too.

This evening I'll be able to be more precise about the exact file, I
don't have the box here.

Stefano Rivoir

unread,

Jul 11, 2007, 10:29:04 AM7/11/07

to Linus Torvalds, Stefano Rivoir, Linux Kernel Mailing List

Yes, I'll file a bug (here and on b.d.o) tonight, when I'll be on the
box again.

Bye.

--
Stefano RIVOIR

Theodore Tso

unread,

Jul 11, 2007, 12:25:33 PM7/11/07

to Stefano Rivoir, Linus Torvalds, Linux Kernel Mailing List

On Wed, Jul 11, 2007 at 08:38:23AM +0200, Stefano Rivoir wrote:
> Probably it's something I had to know before... but the light lit when
> gcc crashed when compiling 2.6.22-git1...

If gcc crashed when compiling 2.6.22-git1, and it didn't crash using
2.6.22, it would be really good idea to git bisect between 2.6.22 and
HEAD, to see what caused the gcc crash.

There may be two issues hiding here; whatever changeset caused the gcc
crash, and whatever change caused your 2.6.22 kernel to hang on boot;
they may not have the same root cause!

- Ted

Martin Orr

unread,

Jul 11, 2007, 1:52:41 PM7/11/07

to Andi Kleen, Stefano Rivoir, Linus Torvalds, Linux Kernel Mailing List

O#n 11/07/07 14:10, Andi Kleen wrote:
> Stefano Rivoir <s.ri...@gts.it> writes:
>> Linus Torvalds wrote:
>>> On Tue, 10 Jul 2007, Stefano Rivoir wrote:
>> Ok, the guilty bit is gcc: in my box, compiling kernel with gcc 4.2.x
>> (which is installed on my debian/sid) turns into a hang (in init,
>> seemingly, maybe not even in kernel itself), while gcc-4.1 is allright.
>
> The standard way to track this down is to compile different directories
> of the kernel with different gcc versions. Then when you find the directory
> go down to files. Then you could eventually go down to functions, although
> that tends to involve quite some editing work. But already knowing
> the file would be useful.

I have done this. The file is arch/x86_64/kernel/signal.c: if I compile
this with gcc 20070627 then everything works, if I compile it with gcc
20070707 then udevsettle hangs. This is independent of the gcc version used
to compile the rest of the kernel. (The dates refer to versions of the
Debian gcc-4.2 package and its dependencies.)

--
Martin Orr

signature.asc

Linus Torvalds

unread,

Jul 11, 2007, 2:02:51 PM7/11/07

to Martin Orr, Andi Kleen, Stefano Rivoir, Linux Kernel Mailing List

On Wed, 11 Jul 2007, Martin Orr wrote:
>
> I have done this. The file is arch/x86_64/kernel/signal.c: if I compile
> this with gcc 20070627 then everything works, if I compile it with gcc
> 20070707 then udevsettle hangs. This is independent of the gcc version used
> to compile the rest of the kernel. (The dates refer to versions of the
> Debian gcc-4.2 package and its dependencies.)

Can you do

make arch/x86_64/kernel/signal.s

with both compilers, and post the results somewhere? It's probably going
to be so large, and have so many trivial differences (register allocation
etc) that it will be hard-to-impossible to see the problem, but at least
we can *try* to see if it might be obvious enough from comparing the
assembly..

(Register allocation differences make comparisons like that really hard,
but if the two compiler versions are close enough, they *might* end up
having sufficiently similar register allocation that the stupid
differences don't hide all the real differences).

Linus

Martin Orr

unread,

Jul 11, 2007, 5:02:54 PM7/11/07

to Linus Torvalds, Andi Kleen, Stefano Rivoir, Linux Kernel Mailing List

On 11/07/07 19:01, Linus Torvalds wrote:
> Can you do
>
> make arch/x86_64/kernel/signal.s
>
> with both compilers, and post the results somewhere? It's probably going
> to be so large, and have so many trivial differences (register allocation
> etc) that it will be hard-to-impossible to see the problem, but at least
> we can *try* to see if it might be obvious enough from comparing the
> assembly..

OK, they are at:
http://www.srcf.ucam.org/~mpo25/2007/linux-signal/

--
Martin Orr

signature.asc

Linus Torvalds

unread,

Jul 11, 2007, 5:31:29 PM7/11/07

to Martin Orr, Andi Kleen, Stefano Rivoir, Linux Kernel Mailing List

On Wed, 11 Jul 2007, Martin Orr wrote:

> On 11/07/07 19:01, Linus Torvalds wrote:
> > Can you do
> >
> > make arch/x86_64/kernel/signal.s
> >
> > with both compilers, and post the results somewhere? It's probably going
>

> OK, they are at:
> http://www.srcf.ucam.org/~mpo25/2007/linux-signal/

Ok, do_notify_resume() which inlines the "setup_frame()" code has has been
totally buggered by the new compiler.

The code is the

err |= __put_user(0, &frame->uc.uc_flags);
err |= __put_user(0, &frame->uc.uc_link);
err |= __put_user(me->sas_ss_sp, &frame->uc.uc_stack.ss_sp);
err |= __put_user(sas_ss_flags(regs->rsp),
&frame->uc.uc_stack.ss_flags);
err |= __put_user(me->sas_ss_size, &frame->uc.uc_stack.ss_size);
err |= setup_sigcontext(&frame->uc.uc_mcontext, regs, set->sig[0], me);
err |= __put_user(fp, &frame->uc.uc_mcontext.fpstate);

and both compilers do a pretty bad job at this, but at least the old
compiler generated the errors properly:

- orl 100(%rsp), %esi # __pu_err, __pu_err
- orl 96(%rsp), %esi # __pu_err, __pu_err
- orl 16(%rsp), %esi # __pu_err, __pu_err
- orl 20(%rsp), %esi # __pu_err, __pu_err
- orl 24(%rsp), %esi # __pu_err, __pu_err
- orl 28(%rsp), %esi # __pu_err, __pu_err
- orl 32(%rsp), %esi # __pu_err, __pu_err
- orl 36(%rsp), %esi # __pu_err, __pu_err
- orl 40(%rsp), %esi # __pu_err, __pu_err
- orl 44(%rsp), %esi # __pu_err, __pu_err
- orl 48(%rsp), %esi # __pu_err, __pu_err
- orl 52(%rsp), %esi # __pu_err, __pu_err
- orl 56(%rsp), %esi # __pu_err, __pu_err
- orl 60(%rsp), %esi # __pu_err, __pu_err
- orl 64(%rsp), %esi # __pu_err, __pu_err
- orl 68(%rsp), %esi # __pu_err, __pu_err
- orl 72(%rsp), %esi # __pu_err, __pu_err
- orl 76(%rsp), %esi # __pu_err, __pu_err
- orl 80(%rsp), %esi # __pu_err, __pu_err
- orl 84(%rsp), %esi # __pu_err, __pu_err
- orl 88(%rsp), %esi # __pu_err, __pu_err
- orl 92(%rsp), %esi # __pu_err, __pu_err

and the new compiler is just incredibly broken:

+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %eax, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err
+ orl %ecx, %esi # __pu_err, __pu_err

I don't think this is worth even trying to fix. This is terminal compiler
breakage. Make a bug-report to the gcc people, the inline asm stuff has
been totally buggered by that compiler version.

If it mis-compiled that part, it probably miscompiled a lot of other
things too.

Andi Kleen

unread,

Jul 11, 2007, 6:16:49 PM7/11/07

to Linus Torvalds, Martin Orr, Andi Kleen, Stefano Rivoir, Linux Kernel Mailing List

> I don't think this is worth even trying to fix. This is terminal compiler
> breakage. Make a bug-report to the gcc people, the inline asm stuff has
> been totally buggered by that compiler version.
>
> If it mis-compiled that part, it probably miscompiled a lot of other
> things too.

I just checked with today's gcc 4.2 (070711) freshly compiled and from a quick inspection
the code looks correct again. So perhaps it has been already fixed?

http://firstfloor.org/~andi/signal.s-070711

Result also boots

Unfortunately the date is not checkable in gcc so we can't easily add #errors.

-Andi

Linus Torvalds

unread,

Jul 11, 2007, 6:38:32 PM7/11/07

to Andi Kleen, Martin Orr, Stefano Rivoir, Linux Kernel Mailing List

On Thu, 12 Jul 2007, Andi Kleen wrote:
>
> I just checked with today's gcc 4.2 (070711) freshly compiled and from a quick inspection
> the code looks correct again. So perhaps it has been already fixed?

Did you see the breakage with the original compiler? It might be some
config setup or something.

But yeah, if Debian/sid is just using random compiler snapshots of the
day, I htink we can just bury this as "pointless".

Who the heck takes a compiler snapshot and runs with it? At least when
your kernel breaks, it seldom breaks subtly (but I would expect that most
distros would not pick random nightly kernel builds). When your compiler
breaks, you have random problems in totally unexpected places, the last
thing you want to have is a random nightly snapshot in a distro - even a
development one.

Strange.

Linus

Andi Kleen

unread,

Jul 11, 2007, 6:43:42 PM7/11/07

to Linus Torvalds, Andi Kleen, Martin Orr, Stefano Rivoir, Linux Kernel Mailing List

On Wed, Jul 11, 2007 at 03:37:41PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 12 Jul 2007, Andi Kleen wrote:
> >
> > I just checked with today's gcc 4.2 (070711) freshly compiled and from a quick inspection
> > the code looks correct again. So perhaps it has been already fixed?
>
> Did you see the breakage with the original compiler? It might be some

No, i don't have a debian compiler and i normally use gcc 4.1 on my
workstation.

BTW I just heard that at least one package in suse STABLE (using a slightly
older gcc 4.2 snapshot) apprently with inline assembly got miscompiled too

> config setup or something.
>
> But yeah, if Debian/sid is just using random compiler snapshots of the
> day, I htink we can just bury this as "pointless".
>
> Who the heck takes a compiler snapshot and runs with it? At least when
> your kernel breaks, it seldom breaks subtly (but I would expect that most
> distros would not pick random nightly kernel builds). When your compiler
> breaks, you have random problems in totally unexpected places, the last
> thing you want to have is a random nightly snapshot in a distro - even a
> development one.

I guess it's because gcc 4.2 is technically supposed to be a -stable tree.

Also recompiling whole distros tends to find a lot of compiler bugs so
I guess it's useful QA for them.

-Andi

Serge Belyshev

unread,

Jul 11, 2007, 6:57:12 PM7/11/07

to Andi Kleen, Linus Torvalds, Martin Orr, Stefano Rivoir, Linux Kernel Mailing List, Matthias Klose

Andi Kleen <an...@firstfloor.org> writes:

>> I don't think this is worth even trying to fix. This is terminal compiler
>> breakage. Make a bug-report to the gcc people, the inline asm stuff has
>> been totally buggered by that compiler version.
>>
>> If it mis-compiled that part, it probably miscompiled a lot of other
>> things too.
>
> I just checked with today's gcc 4.2 (070711) freshly compiled and from a quick inspection
> the code looks correct again. So perhaps it has been already fixed?

No, debian's 4.2-20070707-1 is made from another branch (branches/ubuntu/gcc-4_2-branch)

CC'ing Debian GCC Maintainer, he will be interested.

Stephen Frost

unread,

Jul 11, 2007, 8:09:35 PM7/11/07

to Linus Torvalds, Andi Kleen, Martin Orr, Stefano Rivoir, Linux Kernel Mailing List

* Linus Torvalds (torv...@linux-foundation.org) wrote:

> But yeah, if Debian/sid is just using random compiler snapshots of the
> day, I htink we can just bury this as "pointless".

Err, debian/sid *isn't* defaulting to gcc-4.2 yet, but it is made
available to people who want to install it and play with it.

Additionally, the kernel build is actually tied to a specific compiler
(doesn't default to just using whatever the default compiler is) so even
when gcc-4.2 is eventually made the default compiler the linux images
built for Debian won't use it immediately. That change will be made
seperately and after additional testing to make sure it doesn't break
the built kernel which is distributed.

Thanks,

Stephen

signature.asc

Martin Orr

unread,

Jul 14, 2007, 11:49:12 AM7/14/07

to Andi Kleen, Linus Torvalds, Stefano Rivoir, Linux Kernel Mailing List

On 11/07/07 23:16, Andi Kleen wrote:
> I just checked with today's gcc 4.2 (070711) freshly compiled and from a quick inspection
> the code looks correct again. So perhaps it has been already fixed?

It has indeed been fixed. I tracked the bug down to gcc svn revision 126418
(20070706) and the fix to revision 126487 (20070709).

Best wishes,

--
Martin Orr

signature.asc