Hi all -
There are a few things I do every time I expand the source tree
with sequence-patch.sh.
Or, rather, things I should do and forget to do a lot.
The first I always remember to do: Copy the config I want to test with
to my build directory.
The second I forget more often than not: Expand the kABI references
into my build directory.
One of the things that bites me occasionally is when there are kABI
changes that go un-noticed until the automated build checker flags them
and sends me an email yelling at me for my carelessness.
This patch adds three options to scripts/sequence-patch.sh to take care
of these automatically.
--build-dir=PATH allows you to specify the build directory you'll be
using. It will create the directory if it doesn't exist. It defaults to
$PATCH_DIR.
--config=ARCH-FLAVOR allows you to specify the config you'll use. It
will copy the config to your build directory. It is not a fatal error if
the config does not exist. It will just not copy one.
--kabi allows you to direct sequence-patch to expand the kABI references
into your build directory. Since the references are arch/flavor specific,
it depends on --config=ARCH-FLAVOR. It is not a fatal error if the kABI
reference doesn't exist since this is always the case in the master branch.
The --build-dir PATH is subject to shell expansion. It is expanded late
enough in the script that most variables should be available.
There are also three new variables available when --config is used:
$CONFIG contains the --config contents. $CONFIG_ARCH contains the arch
part of the config. $CONFIG_FLAVOR contains the flavor part.
For reference, I have this in my .bashrc:
export SEQUENCE_PATCH_ARGS="--config=x86_64-desktop --build-dir=~/src/scratch/build/\$CONFIG_ARCH/linux-\$SRCVERSION-\$TAG-\$CONFIG_FLAVOR --kabi"
I've also added patches for --ctags and --cscope which will automatically
generate the databases for either of those tools in the build directory
after the source tree is expanded.
- Issues addressed in patchset #2:
- Help text is now a here document for easy addition of more documentation
- Explanation of which variables are allowed by --build-dir
- Missing rpm/modversions script is not an error on older branches
- Missing symvers files are not errors
- Uses true/false for simple feature flags
-Jeff
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
we have in glibc a patch that reverts this commit:
2003-02-20 Ulrich Drepper <drepper(a)redhat.com>
* sysdeps/unix/sysv/linux/tcsetattr.c (tcsetattr): Remove obsolete
patch to check for system call errors.
I don't have a comment why the patch is needed. Both Fedora and us have the
patch in their current glibc versions.
Can any of you comment on whether we still need this with recent (2.6.32 or
newer) kernels or not?
Andreas
Index: sysdeps/unix/sysv/linux/tcsetattr.c
===================================================================
--- sysdeps/unix/sysv/linux/tcsetattr.c.orig
+++ sysdeps/unix/sysv/linux/tcsetattr.c
@@ -49,6 +49,7 @@ tcsetattr (fd, optional_actions, termios
{
struct __kernel_termios k_termios;
unsigned long int cmd;
+ int retval;
switch (optional_actions)
{
@@ -80,6 +81,35 @@ tcsetattr (fd, optional_actions, termios
memcpy (&k_termios.c_cc[0], &termios_p->c_cc[0],
__KERNEL_NCCS * sizeof (cc_t));
- return INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios);
+ retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios);
+
+ if (retval == 0 && cmd == TCSETS)
+ {
+ /* The Linux kernel has a bug which silently ignore the invalid
+ c_cflag on pty. We have to check it here. */
+ int save = errno;
+ retval = INLINE_SYSCALL (ioctl, 3, fd, TCGETS, &k_termios);
+ if (retval)
+ {
+ /* We cannot verify if the setting is ok. We don't return
+ an error (?). */
+ __set_errno (save);
+ retval = 0;
+ }
+ else if ((termios_p->c_cflag & (PARENB | CREAD))
+ != (k_termios.c_cflag & (PARENB | CREAD))
+ || ((termios_p->c_cflag & CSIZE)
+ && ((termios_p->c_cflag & CSIZE)
+ != (k_termios.c_cflag & CSIZE))))
+ {
+ /* It looks like the Linux kernel silently changed the
+ PARENB/CREAD/CSIZE bits in c_cflag. Report it as an
+ error. */
+ __set_errno (EINVAL);
+ retval = -1;
+ }
+ }
+ }
+
+ return retval;
--
Andreas Jaeger, Program Manager openSUSE
aj(a){novell.com,suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi,
The opensuse kernel git trees have a new home at
http://kernel.opensuse.org/?a=git . It should be more reliable than
gitorious, which sometimes has problems cloning the nearly 1GB
repository. We continue to sync to gitorious as well, so nothing should
break for anyone. If you want to switch an existing clone to
kernel.opensuse.org, however, it's as simple as
git config remote.origin.url \
git://kernel.opensuse.org/kernel-source.git
and analogously for the kernel.git repository. We will add more stuff to
kernel.opensuse.org website in near future, next in the todo list is LXR
and either gitweb or cgit.
Have fun!
Michal
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
-------- Original Message --------
Subject: Re: [opensuse-kernel] PATA devices being configured with wrong
UDMA
Date: Mon, 23 May 2011 17:47:48 +1000
From: Basil Chupin <blchupin(a)iinet.net.au>
To: opensuse-kernel(a)opensuse.org
On 21/05/11 01:35, Jean Delvare wrote:
> Hi Basil,
>
> Le vendredi 20 mai 2011 16:36, Basil Chupin a écrit :
>> (Won't go into reasons, but it has to do with openSUSE and audio and
>> pulseaudio and getting different results when installing the same copy
>> of 11.4/KDE on the same system.......but let's not get into this one
>> right now, OK? :-D .)
> Don't tell me about sound and pulseaudio :(
I won't ever again, I promise (until the next time) :-) .
> More seriously, comparisons like this are very difficult to
> establish, and are often biased by personal experience.
>
> Out of curiosity, did you try a different operating system on the
> same hardware, to see if it was doing any better with UDMA speed
> detection?
I had no intention of this going into some sort of a bun-fight over what
seems to be a simple matter - and I still have no intention of this
going into such a state.
I asked a simple question which was about what was the correct format to
use in the "libata.force" statement to get both PATA channels working
with an 80-wire cable; to show why I was asking the question I gave an
extract from the boot.msg log file as well as making the comment that
this hassle with the kernel incorrectly deciding that the machine was
using a 40-wire cable has been known since at least 2008.
I received from you the answer as to what was the correct format to use
for this over-riding kernel parameter. Wonderful! But then the
(unintended) "fight" started :-D .
To save space and time what I deliberately omitted from my original post
was that I had the following configuration a couple of weeks before I
posted my question:
PATA #1 : WD HD with UDMA 133
LG CDROM with UDMA 33
PATA #2: Seagate with UDMA 100
Pioneer DVD-RW UDMA 100
and the kernel was giving me the correct UDMA settings for PATA #1 (UDMA
133/33) [NOTE: 133/33] *without* any "libata fix" but I had to use
"libata.force=2:80c" to get the correct UDMA set for PATA #2.
This was all fine until I had to replace the LG CDROM (UDMA 33) with the
new Pioneer DVD-RW which has UDMA 100.
(And this one is for Stefan: NOTE that the UDMA was set correctly on
PATA #1 *without* any "libata" fiddles for #1 - so, the chip is working
fine, right?)
When I did replace the LG CDROM on PATA #1 with a new Pioneer DVD-RW -
so that I now had the Maxtor UDMA 133 with the DVD-RW UDMA 100 - the
kernel decided that I had a 40-wire cable connected on PATA #1 and made
both devices UDMA 33.
PATA #2 was still correctly set (to 100/100) by the entry of
"libata.force=2:80c".)
This is when I posted my message of help for the correct format of the
wording to get BOTH channels set to the correct UDMA by the kernel.
Now, 2 things are associated with this:
(1) how did I learn that the kernel required the fiddle of
"libata.force=..."? because I searched the net and found many references
to this problem but the one which gave me the most acceptable solution
(others where to recompile the kernel after setting the appropriate
parameter already existing in the kernel, and applying a patch to the
kernel) was the one I found here:
http://viktorbalogh.net/blog/other/libata-workaround-limited-to-udma33-due-…
;
(2) why did I ask my question here and not in some "kernel upstream"
list? I did so because there is a self-appointed "mail list cop" who
inhabits opensuse help mail list and told me off for asking the question
about KDE in the opensuse help list but which have been asked in the KDE
mail list - which meant that "as good little soldier" I should ask my
question about the kernel in *this* mail list to avoid the wrath of that
"list cop" :-) . And, secondly, I don't know any "upstream kernel" list
nor did I think that I needed to do so just to have a simple question
about the correct wording format to use to get the "fix" working.
My real problem was in adding my comments about this kernel problem
being known for at least 3 years and for which I shall now go and put on
my hair-shirt, kneel on a bed of hot ashes and flagellate myself
for......oh, I don't know - perhaps several nano seconds or so? :-) .
Lastly, you asked if I had this hassle on other distros. The answer is
YES - and at least one uses a more up-to-date version of the kernel (eg,
Ubuntu). In all cases the only "libata fix" I had to use was to set PATA
#2 to be correct, because I still had the LG CDROM on PATA #1 and the
UDMA for devices on PATA #1 were being set correctly. However, since
getting the new RW on #1 I have not used the other distros so cannot say
what the results would be if I did.
(I wouldn't be having this drawn out discussion to justify my
results/question if I hadn't had to replace the LG CDROM on PATA #1 with
the Pioneer DVD-RW :'( .
But life wouldn't be so interesting without such little PITAs, would it?
:-D )
BC
--
"The time has been
That, when the brains were out, the man would die,"
"Macbeth", Shakespeare
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
In openSUSE:Tumbleweed we have the latest kernel-firmware package, which
should be something like kernel-firmware-20101214 or so.
But something else is generating the package,
kernel-firmware-2.6.38-34.2.noarch which should be older and not used
anymore. It's odd that the kernel version number shows up here as well.
I can't seem to figure out what is doing this, anyone have any ideas?
confused,
greg k-h
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi,
while I was looking at the Kernel:* repositories, I spotted there is
v2.6.35 kernel. It seems to be broken and quite outdated. So in fact, it
only wastes the BS power. I think the repository should be deleted. What
do you think? Is there anything why it is preserved?
thanks,
--
js
suse labs
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hello,
is this a normal Log in the last Kernels?
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
I have a lot of this in my Log files
--
mit freundlichen Grüßen / best Regards,
Günther J. Niederwimmer
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
I am running 32-bit openSUSE 11.4 (have both KDE and Gnome installed on
separate sets of HDs); installed as fresh installations. The kernel used
is the one installed by 11.4.
I am using both ATA controllers each with same model HDs and same model
DVDRWs sitting on 80-wire cables and set for Cable Select.
Before I do a "fiddle" - see below - the HDs and the DVDRWs on both
channels are set during boot to UDMA 33 because the kernel decides that
I am using a 40-wire cable on each controller.
I found a reference going back to 2008 that this is a known problem in
the kernel and that adding "libata.force=X:80c" to the kernel parameters
in menu.lst works around this annoyance.
Putting in "libata.force=1:80c" gives me the correct UDMAs for what is
on controller #1 but what is on #2 is set to UDMA 33.
So I put in "libata.force=1,2:80c" 'cause I read that one uses a comma
as a separator in such "libata" statement but this don't work and only
the second controller is configured correctly :-( .
Here is an extract from boot.msg showing this:
1.482242] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
1.482246] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
1.617516] usb 2-1: New USB device found, idVendor=03f0, idProduct=bb02
1.617520] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
1.617523] usb 2-1: Product: Photosmart 8400 series
1.617525] usb 2-1: Manufacturer: HP
1.617527] usb 2-1: SerialNumber: CN52N211850469
1.620813] scsi2 : usb-storage 2-1:1.2
1.688318] ata1.00: HPA unlocked: 490232639 -> 490234752, native 490234752
1.688324] ata1.00: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133
<===========XXXXXXXXXXXXXX
1.688328] ata1.00: 490234752 sectors, multi 16: LBA48
1.688335] ata1.01: ATAPI: PIONEER DVD-RW DVR-118L, 1.02, max UDMA/100
<======XXXXXXXXXXXXXX
1.688344] ata1: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000
(0xc7c6c7c6) ACPI=0x7f01f (15:20:0x1f)
1.688347] ata1.00: limited to UDMA/33 due to 40-wire cable
1.688352] ata1: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000
(0xc7c6c7c6) ACPI=0x3f01f (15:20:0x1f)
1.688355] ata1.01: limited to UDMA/33 due to 40-wire cable
1.695812] ata1.00: configured for UDMA/33 <==============XXXXXXXXXXXXXX
1.717242] ata1.01: configured for UDMA/33 <==============XXXXXXXXXXXXXX
1.717784] scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250R0 BAH4
PQ: 0 ANSI: 5
1.721008] sd 0:0:0:0: [sda] 490234752 512-byte logical blocks: (251
GB/233 GiB)
1.721070] scsi 0:0:1:0: CD-ROM PIONEER DVD-RW DVR-118L 1.02
PQ: 0 ANSI: 5
1.721335] sd 0:0:0:0: [sda] Write Protect is off
1.721339] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
1.721368] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled,
doesn't support DPO or FUA
1.808862] sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 >
1.809367] sd 0:0:0:0: [sda] Attached SCSI disk
1.878316] ata2: FORCE: cable set to 80c <=============ZZZZZZZZZZZZZZZZZZZ
1.879907] ata2.00: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133
<===ZZZZZZZZZZZZZZZZZZZ
1.879910] ata2.00: 490234752 sectors, multi 16: LBA48
1.879917] ata2.01: ATAPI: PIONEER DVD-RW DVR-118L, 1.02, max UDMA/100
<==ZZZZZZZZZZZZZZZZ
1.879925] ata2: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000
(0xc7c6c7c6) ACPI=0x7f01f (15:20:0x1f)
1.879930] ata2: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000
(0xc7c6c7c6) ACPI=0x3f01f (15:20:0x1f)
1.881012] usb 2-2: new low speed USB device using ohci_hcd and address 3
1.887783] ata2.00: configured for UDMA/133 <===========ZZZZZZZZZZZZZZZ
1.909241] ata2.01: configured for UDMA/100 <===========ZZZZZZZZZZZZZZZ
Could someone please tell me what the correct words to use to get both
all the devices configured with the correct UDMA?
Perhaps there is another way of doing this other than what was provided
way back 3 years ago? (Such a bug in the kernel still around after 3 years?)
BTW, HDPARM for /dev/sda and sdb supports the results shown above in
boot.msg
BC
--
"The older the violin the sweeter the music."
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
All,
I'm trying to patch in a new module for my testing.
osc build is failing both on OBS and locally because the config
question is unexpected
How do I pre-answer that question?
=== log of failure
The Extended 4 (ext4) filesystem (EXT4_FS) [M/n/y/?] m
Ext4 extended attributes (EXT4_FS_XATTR) [Y/n/?] y
Ext4 POSIX Access Control Lists (EXT4_FS_POSIX_ACL) [Y/n/?] y
Ext4 Security Labels (EXT4_FS_SECURITY) [Y/n/?] y
EXT4 debugging support (EXT4_DEBUG) [N/y/?] n
EXT4 snapshots (Experimental) (EXT4_FS_SNAPSHOT) [N/y/?] (NEW) aborted!
Console input/output is redirected. Run 'make oldconfig' to update
configuration.
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** [sub-make] Error 2
make: Leaving directory
`/usr/src/packages/BUILD/kernel-desktop-2.6.38.5/linux-2.6.38'
error: Bad exit status from /var/tmp/rpm-tmp.qOSXbc (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.qOSXbc (%prep)
The buildroot was: /var/tmp/build-root
========
Greg
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
