from:"Stephan Schreiber"


Package: src:linux
Version: 3.2.35-2
Severity: important
Tags: patch


The Linux Kernel contains some inline assembly source code which has  
wrong asm register constraints in arch/ia64/kvm/vtlb.c.


File arch/ia64/kvm/vtlb.c:

u64 guest_vhpt_lookup(u64 iha, u64 *pte)
{
u64 ret;
struct thash_data *data;

data = __vtr_lookup(current_vcpu, iha, D_TLB);
if (data != NULL)
thash_vhpt_insert(current_vcpu, data-page_flags,
data-itir, iha, D_TLB);

asm volatile (
rsm psr.ic|psr.i;;
srlz.d;;
ld8.s r9=[%1];;
tnat.nz p6,p7=r9;;
(p6) mov %0=1;
(p6) mov r9=r0;
(p7) extr.u r9=r9,0,53;;
(p7) mov %0=r0;
(p7) st8 [%2]=r9;;
ssm psr.ic;;
srlz.d;;
ssm psr.i;;
srlz.d;;
: =r(ret) : r(iha), r(pte):memory);

return ret;
}

The list of output registers is
: =r(ret) : r(iha), r(pte):memory);
The constraint =r means that the GCC has to maintain that these vars  
are in registers and contain valid info when the program flow leaves  
the assembly block (output registers).
But =r also means that GCC can put them in registers that are used  
as input registers. Input registers are iha, pte on the example.

If the predicate p7 is true, the 8th assembly instruction
(p7) mov %0=r0;
is the first one which writes to a register which is maintained by the  
register constraints; it sets %0. %0 means the first register operand;  
it is ret here.
This instruction might overwrite the %2 register (pte) which is needed  
by the next instruction:

(p7) st8 [%2]=r9;;
Whether it really happens depends on how GCC decides what registers it  
uses and how it optimizes the code.



The attached patch  fixes the register operand constraints in  
arch/ia64/kvm/vtlb.c.

The register constraints should be
: =r(ret) : r(iha), r(pte):memory);
The  means that GCC must not use any of the input registers to place  
this output register in.


Stephan




kvm-ia64.patch
Description: kvm-ia64.patch

Bug#702641: ia64, wrong asm register contraints in the futex implementation


Package: src:linux
Version: 3.2.23-1
Severity: important
Tags: patch


The Linux Kernel contains some inline assembly source code which has  
wrong asm register constraints in arch/ia64/include/asm/futex.h.
Since it causes trouble when compiling the Kernel with GCC4.4, it  
should be fixed.


File arch/ia64/include/asm/futex.h:

static inline int
futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
  u32 oldval, u32 newval)
{
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;

{
register unsigned long r8 __asm (r8);
unsigned long prev;
__asm__ __volatile__(
  mf;;\n
  mov %0=r0   \n
  mov ar.ccv=%4;; \n
[1:]  cmpxchg4.acq %1=[%2],%3,ar.ccv  \n
  .xdata4 \__ex_table\, 1b-., 2f-.\n
[2:]
: =r (r8), =r (prev)
: r (uaddr), r (newval),
  rO ((long) (unsigned) oldval)
: memory);
*uval = prev;
return r8;
}
}



The list of output registers is
: =r (r8), =r (prev)
The constraint =r means that the GCC has to maintain that these vars  
are in registers and contain valid info when the program flow leaves  
the assembly block (output registers).
But =r also means that GCC can put them in registers that are used  
as input registers. Input registers are uaddr, newval, oldval on the  
example.

The second assembly instruction
  mov %0=r0   \n
is the first one which writes to a register; it sets %0 to 0. %0 means  
the first register operand; it is r8 here. (The r0 is read-only and  
always 0 on the Itanium; it can be used if an immediate zero value is  
needed.)
This instruction might overwrite one of the other registers which are  
still needed.
Whether it really happens depends on how GCC decides what registers it  
uses and how it optimizes the code.


The objdump utility can give us disassembly.
The futex_atomic_cmpxchg_inatomic() function is inline, so we have to  
look for a module that uses the funtion. This is the  
cmpxchg_futex_value_locked() function in

kernel/futex.c:

static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr,
  u32 uval, u32 newval)
{
int ret;

pagefault_disable();
ret = futex_atomic_cmpxchg_inatomic(curval, uaddr, uval, newval);
pagefault_enable();

return ret;
}


Now the disassembly. At first from the Kernel package 3.2.23 which has  
been compiled with GCC 4.4, remeber this Kernel seemed to work:

objdump -d linux-3.2.23/debian/build/build_ia64_none_mckinley/kernel/futex.o

0230 cmpxchg_futex_value_locked:
 230:   0b 18 80 1b 18 21   [MMI]   adds r3=3168,r13;;
 236:   80 40 0d 00 42 00   adds r8=40,r3
 23c:   00 00 04 00 nop.i 0x0;;
 240:   0b 50 00 10 10 10   [MMI]   ld4 r10=[r8];;
 246:   90 08 28 00 42 00   adds r9=1,r10
 24c:   00 00 04 00 nop.i 0x0;;
 250:   09 00 00 00 01 00   [MMI]   nop.m 0x0
 256:   00 48 20 20 23 00   st4 [r8]=r9
 25c:   00 00 04 00 nop.i 0x0;;
 260:   08 10 80 06 00 21   [MMI]   adds r2=32,r3
 266:   00 00 00 02 00 00   nop.m 0x0
 26c:   02 08 f1 52 extr.u r16=r33,0,61
 270:   05 40 88 00 08 e0   [MLX]   addp4 r8=r34,r0
 276:   ff ff 0f 00 00 e0   movl r15=0xfffbfff;;
 27c:   f1 f7 ff 65
 280:   09 70 00 04 18 10   [MMI]   ld8 r14=[r2]
 286:   00 00 00 02 00 c0   nop.m 0x0
 28c:   f0 80 1c d0 cmp.ltu p6,p7=r15,r16;;
 290:   08 40 fc 1d 09 3b   [MMI]   cmp.eq p8,p9=-1,r14
 296:   00 00 00 02 00 40   nop.m 0x0
 29c:   e1 08 2d d0 cmp.ltu p10,p11=r14,r33
 2a0:	56 01 10 00 40 10 	[BBB] (p10) br.cond.spnt.few 2e0  
cmpxchg_futex_value_locked+0xb0
 2a6:	02 08 00 80 21 03 	  (p08) br.cond.dpnt.few 2b0  
cmpxchg_futex_value_locked+0x80
 2ac:	40 00 00 41   	  (p06) br.cond.spnt.few 2e0  
cmpxchg_futex_value_locked+0xb0

 2b0:   0a 00 00 00 22 00   [MMI]   mf;;
 2b6:   80 00 00 00 42 00   mov r8=r0
 2bc:   00 00 04 00 nop.i 0x0
 2c0:   0b 00 20 40 2a 04   [MMI]   mov.m ar.ccv=r8;;
 2c6:   10 1a 85

Bug#642750: GDB stops with sigtrap at 0 address on ia64 wheezy


notfound 642750 src:linux/3.5.5-1~experimental.1
notfixed 642750 linux-image-3.0.0-2-mckinley/3.0.0-5
notfixed 642750 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
fixed 642750 3.2.35-2
thanks


The problem with GDB does no longer occur with Kernel 3.2.35-2. I  
don't have a clue why.

A user has confimred that on the debian-i...@lists.debian.org list.

I filed a new bug#702641 for the asm register contraints problem above.

Please could you simply close this bug?

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642750: GDB stops with sigtrap at 0 address on ia64 wheezy


I'm sorry. Wrong bug number.
Please, ignore my message.

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy


notfound 691576 src:linux/3.5.5-1~experimental.1
notfixed 691576 linux-image-3.0.0-2-mckinley/3.0.0-5
notfixed 691576 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
fixed 691576 3.2.35-2
thanks


The problem with GDB does no longer occur with Kernel 3.2.35-2. I  
don't have a clue why.

A user has confimred that on the debian-i...@lists.debian.org list.

I filed a new bug#702641 for the asm register contraints problem above.

Please could you simply close this bug?

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679545: [ia64 SR870] ata_piix: probe fails due to ICH4 EXBAR left cleared

Here is the tentative patch of Bjorn Helgaas  
(https://lkml.org/lkml/2012/9/24/623) - slightly modified in order to  
apply it on Kernel 3.2.35.


Just for the case that someone wants to build an own Kernel.

Stephan



pci-helgaas.patch
Description: pci-helgaas.patch

Bug#700447: ia64, xserver-xorg-video-all package doesn't install some xorg video drivers

2013-02-12 Thread Stephan Schreiber


Package: xserver-xorg-video-all
Version: 1:7.7+1
Severity: serious


The xserver-xorg-video-all package doesn't install the following xorg  
video drivers on ia64:



xserver-xorg-video-apm
xserver-xorg-video-ark
xserver-xorg-video-chips
xserver-xorg-video-cirrus
xserver-xorg-video-i128
xserver-xorg-video-i740
xserver-xorg-video-mga
xserver-xorg-video-rendition
xserver-xorg-video-s3
xserver-xorg-video-siliconmotion
xserver-xorg-video-sis
xserver-xorg-video-trident
xserver-xorg-video-tseng
xserver-xorg-video-vesa


Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700446: ia64, xserver-xorg-video-ati package doesn't install mach64, r128 drivers

2013-02-12 Thread Stephan Schreiber


Package: xserver-xorg-video-ati
Version: 1:6.14.4-6
Severity: serious




Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G
Graphics: build-in ATI Rage XL
01:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI Rage XL [1002:4752] (rev 27)
Subsystem: Intel Corporation Device [8086:3404]


I tried a fresh installation of wheezy.
I realized that the mach64 and the r128 xorg video drivers aren't  
installed automatically on ia64.


Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#560026: [PATCH] yorick test2.i fails with mathlib signals error on ia64

2013-01-05 Thread Stephan Schreiber


found 560026 2.2.02+dfsg-6
notfound 560026 2.1.05 2.1.05+dfsg+cvs20091202-1
# these versions are over; I think, nobody wants to patch them anymore
tags 560026 - help
tags 560026 + patch
thanks



The problem is in the source code file yorick/std0.c, line 1355, in  
the function expLoop():


static void expLoop(double *dst, double *src, long n)
{
  long i;
  for (i=0 ; in ; i++) {
dst[i]= exp(src[i]);
if (errno) { if (errno==ERANGE  !dst[i]) errno=0; else break; }
  }
}


The function calculates the mathematical exp function for each item of  
the src array.
One item is -744.668 (IEEE754 representation C08745590D710CC1) when  
the test runs. The exp() function sets errno to 34 (ERANGE) upon that  
and returns the IEEE754 representation 0001. This is  
around 4.94066E-324, a denormalized value; means underflow.


As you see above, the idea of the expLoop() code is to commute a  
result to 0 if exp() returns an underflow upon (large) negative  
exponents.


Unfortunately it doesn't work for the example since the check for a  
result of 0 - the

!dst[i]
evaluates to 0 (false).
Since errno isn't 0 after that, the yorick interpreter stops the  
execution of the script and reports the seen error message:

ERROR (escout) mathlib function signals error
  LINE: 251  FILE: /usr/lib/yorick/i/test2.i
yorick: quitting on error in batch mode

Obviously the floating point arithmetic doesn't behave in the same way  
on the different archs in 'subnormal' cases.
I assume, the exp() function returns denormalized values on ia64 but  
round them down to 0 on other archs.


My proposal is to the check the arg of exp() rather than the result in  
order to determine whether it is an underflow or not:

(Note that the pointer dst may be equal to the src pointer.)

static void expLoop(double *dst, double *src, long n)
{
  long i;
  for (i=0 ; in ; i++) {
double e = src[i];
dst[i]= exp(e);
if (errno) { if (errno==ERANGE  e0.0) errno=0; else break; }
  }
}

The test does no longer fail, and can be enabled on ia64.

Stephan



fix-exp-underflow.patch
Description: fix-exp-underflow.patch


enable-test-on-ia64.patch
Description: enable-test-on-ia64.patch

Bug#697172: ia64 (Itanium), sporadic crashes of epiphany browser due to a thread-unsafe favicon database


Package: libwebkitgtk-3.0-0
Version: 1.8.1-3.3
Severity: serious
Tags: patch


Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G


I realized this bug while working on bug#642750.


Some assertions fail on the debug build of webkit:

at Source/JavaScriptCore/wtf/RefCounted.h:53
ASSERT(m_verifier.isSafeToUse());

at Source/JavaScriptCore/wtf/RefCounted.h:122
ASSERT(m_verifier.isSafeToUse());




Stacktraces were:

Breakpoint 1, WTFReportAssertionFailure (
file=0x256983c0 ../Source/JavaScriptCore/wtf/RefCounted.h,
line=53, function=0x25699638 void WTF::RefCountedBase::ref(),
assertion=0x256983f0 m_verifier.isSafeToUse())
at ../Source/JavaScriptCore/wtf/Assertions.cpp:219
219 if (assertion)
#0  WTFReportAssertionFailure (
file=0x256983c0 ../Source/JavaScriptCore/wtf/RefCounted.h,
line=53, function=0x25699638 void WTF::RefCountedBase::ref(),
assertion=0x256983f0 m_verifier.isSafeToUse())
at ../Source/JavaScriptCore/wtf/Assertions.cpp:219
#1  0x21e90ba0 in WTF::RefCountedBase::ref (this=0x200010033a00)
at ../Source/JavaScriptCore/wtf/RefCounted.h:53
#2  0x21f43be0 in WTF::refIfNotNullWebCore::SharedBuffer (
ptr=0x200010033a00) at ../Source/JavaScriptCore/wtf/PassRefPtr.h:46
#3  0x2341e8d0 in WTF::RefPtrWebCore::SharedBuffer::operator= (
this=0x608d0920, optr=0x200010033a00)
at ../Source/JavaScriptCore/wtf/RefPtr.h:132
#4  0x2388e190 in WebCore::BMPImageReader::setData (
this=0x608d0910, data=0x200010033a00)
at ../Source/WebCore/platform/image-decoders/bmp/BMPImageReader.h:72
#5  0x238a9ce0 in WebCore::ICOImageDecoder::decodeAtIndex (
this=0x2000100468c0, index=0)
at ../Source/WebCore/platform/image-decoders/ico/ICOImageDecoder.cpp:203
#6  0x238a9370 in WebCore::ICOImageDecoder::decode (
this=0x2000100468c0, index=0, onlySize=false)
at ../Source/WebCore/platform/image-decoders/ico/ICOImageDecoder.cpp:168
#7  0x238a8b10 in WebCore::ICOImageDecoder::frameBufferAtIndex (
this=0x2000100468c0, index=0)
at ../Source/WebCore/platform/image-decoders/ico/ICOImageDecoder.cpp:125
#8  0x237e79c0 in WebCore::ImageSource::createFrameAtIndex (
this=0x200010046838, index=0)
at ../Source/WebCore/platform/graphics/ImageSource.cpp:138
#9  0x236d7cb0 in WebCore::BitmapImage::cacheFrame (
this=0x200010046800, index=0)
at ../Source/WebCore/platform/graphics/BitmapImage.cpp:127
#10 0x236d96c0 in WebCore::BitmapImage::frameAtIndex (
this=0x200010046800, index=0)
at ../Source/WebCore/platform/graphics/BitmapImage.cpp:266
#11 0x255f1690 in WebCore::BitmapImage::getGdkPixbuf (
this=0x200010046800)
at ../Source/WebCore/platform/graphics/gtk/ImageGtk.cpp:115
#12 0x21ef89b0 in getIconPixbufSynchronously (
database=0x600781c0, pageURL=..., iconSize=...)
at ../Source/WebKit/gtk/webkit/webkitfavicondatabase.cpp:401
#13 0x21ef9090 in webkit_favicon_database_try_get_favicon_pixbuf (
database=0x600781c0,
pageURI=0x60076cd0 http://www.gmx.net/;, width=16, height=16)
at ../Source/WebKit/gtk/webkit/webkitfavicondatabase.cpp:442
#14 0x40091360 in set_row_in_model (row=0x60858660,
position=1, model=0x6018cca0) at ephy-completion-model.c:213
#15 replace_rows_in_model (new_rows=0x6088ada0,
model=0x6018cca0) at ephy-completion-model.c:244
#16 query_completed_cb (service=0x601abb70, success=1,
result_data=0x601f0ec0, user_data=0x608fe560)
at ephy-completion-model.c:411
#17 0x400fc670 in ephy_history_service_execute_job_callback (
data=0x608c09e0) at ephy-history-service.c:435
#18 0x2980aa00 in g_idle_dispatch ()
   from /lib/ia64-linux-gnu/libglib-2.0.so.0
#19 0x29810f20 in g_main_context_dispatch ()
   from /lib/ia64-linux-gnu/libglib-2.0.so.0
#20 0x29811740 in ?? () from /lib/ia64-linux-gnu/libglib-2.0.so.0
#21 0x29811ad0 in g_main_context_iteration ()
   from /lib/ia64-linux-gnu/libglib-2.0.so.0
#22 0x29384d00 in g_application_run ()
   from /usr/lib/ia64-linux-gnu/libgio-2.0.so.0
#23 0x40040020 in main (argc=1, argv=0x6fffb458)
at ephy-main.c:483
No symbol m_verifier in current context.
#1  0x21e90ba0 in WTF::RefCountedBase::ref (this=0x200010033a00)
at ../Source/JavaScriptCore/wtf/RefCounted.h:53
53  ASSERT(m_verifier.isSafeToUse());
$3 = {m_mode = WTF::ThreadRestrictionVerifier::MutexVerificationMode,
  m_shared = true, m_owningThread = 0, m_mutex = 0x6024e7d8}
Continuing.

Breakpoint 1, WTFReportAssertionFailure (
file=0x25683b80 ../Source/JavaScriptCore/wtf/RefCounted.h,
line=122,
function=0x25683cf0

Bug#697173: ia64 (Itanium), race condition on the start of the history service thread


Package: epiphany-browser
Version: 3.4.2-2
Severity: serious
Tags: patch


Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G


While working on bug#642750, I realized a failing assertion in the  
epiphany browser:

at lib/history/ephy-history-service.c:363
  g_assert (priv-history_thread == g_thread_self ());

The assertion failed almost often upon the start of epiphany browser;  
sometimes epiphany could start with success.



The ephy_history_service_init() function creates a new thread (using  
g_thread_new()); run_history_service_thread() is the starting function  
of the thread.


static void
ephy_history_service_init (EphyHistoryService *self)
{
  self-priv = EPHY_HISTORY_SERVICE_GET_PRIVATE (self);

  self-priv-history_thread = g_thread_new (EphyHistoryService,  
(GThreadFunc) run_history_service_thread, self);

  self-priv-queue = g_async_queue_new ();
}


static gpointer
run_history_service_thread (EphyHistoryService *self)
{
  EphyHistoryServicePrivate *priv = self-priv;
  EphyHistoryServiceMessage *message;

  g_assert (priv-history_thread == g_thread_self ());

  if (ephy_history_service_open_database_connections (self) == FALSE)
return NULL;

  do {
message = g_async_queue_try_pop (priv-queue);
if (!message) {
  /* Schedule commit if needed. */
  if (ephy_history_service_is_scheduled_to_commit (self))
ephy_history_service_commit (self);

  /* Block the thread until there's data in the queue. */
  message = g_async_queue_pop (priv-queue);
}

/* Process item. */
ephy_history_service_process_message (self, message);

  } while (!ephy_history_service_is_scheduled_to_quit (self));

  ephy_history_service_close_database_connections (self);
  ephy_history_service_execute_quit (self, NULL, NULL);

  return NULL;
}

The third non-empty line of run_history_service_thread() is the  
failing assertion.


The assertion fails because the created thread can execute its code  
before g_thread_new() returns and before the history_thread member is  
initialized.
Whether it happens or not depends on how the operating system  
schedules the processors to the threads.


The history_thread member isn't any problem; it is used just for the  
assertions.
But there is also an async queue (-queue) which is initialized  
*after* creating the new thread in ephy_history_service_init(). This  
means that the code in run_history_service_thread() touches the queue  
when it isn't initialized or while the queue is being initialized by  
the main thread.

That isn't healthy; this can result in data corruption.

The patch
- fixes the issue with the queue, and
- fixes the mentioned assertion.

Although it was experienced on ia64, the bug affects all archs.


You can find a link to the built debs on bug report#642750.

Stephan



history-thread-startup-race.patch
Description: history-thread-startup-race.patch

Bug#697174: ia64 (Itanium), epiphany-browser, please enable seed


Package: epiphany-browser
Version: 3.4.2-2
Severity: serious



Please could you enable seed again on ia64 when seed does no longer  
FTBFS and works (bug#582774) due to the fixes for webkitgtk package on  
ia64 (bug#642750, bug#694971, bug#697172).
Please remember that the epiphany-browser package has to depend on  
libseed-gtk3-0 again after that.


Please could you check whether enabling seed is also possible on MIPS  
since the mentioned bug reports may fix webkit and seed on MIPS as well.


Many thanks.

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642750: epiphany-browser: HIGHLY unstable on ia64 (IA-64/IPF/Itanium) platform


I filed bug#697172 for yet another bug of webkit.
Furthermore, bug#697173 for a bug in the epiphany-browser package.
Furthermore, bug#697174 in order to enable seed on ia64.

I also realized that gnash seems to crash epiphany sometimes. I  
browsed through the Debian bug reports and found ones which blame  
gnash to make the webkit based browsers unstable - epiphany-bowser on  
Gnome and Konqueror on KDE:

bug#594822, 655839, 549309.
I removed both gnash and gnash-common from my computer and realized a  
real improvement of epiphany's behaviour.


But I still experienced some trouble, for example, a reproducable  
hang-up and a crash a few seconds subsequently: Enter www.kununu.de;  
enter a company name in the top right search edit box; enter; click on  
a company's name - hang-up, crash.
I tried Fedora 17 i386 on another box (epiphany-browser 3.4.3; webkit  
1.8.3; gnash isn't installed): same behaviour. It isn't an ia64  
specific bug.


I think epiphany-browser/webkit with all patches runs on ia64 as  
stable as on x86; this is the best we can do at the moment.



A summary of the patches we had so far:

webkit, this bug report
01-ia64-wide-ptr.patch
02-ia64-use-system-malloc.patch

webkit, bug#694971
large-mem-page.patch

webkit, bug#697172
thread-safe-icon-db.patch

seed, bug#582774
seed no longer FTBFS without any change

epiphany-browser, bug#697173
history-thread-startup-race.patch

epiphany-browser, bug#697174
enabling seed in debian/rules


If you want to test it, you can download the built debs:

http://www.fs-driver.org/debian-ia64/webkitgtk-debs-v3.tar
http://www.fs-driver.org/debian-ia64/seed-debs.tar
http://www.fs-driver.org/debian-ia64/epiphany-debs.tar

Remember to remove both gnash and gnash-common before you test it.

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696961: qt4-x11: parallel build disabled on non-ia64 archs

2012-12-30 Thread Stephan Schreiber

Obviously the revert-ia64-remove-parallel.patch of bug#696096  
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696096#5) wasn't  
applied correctly.


Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696961: parallel build disabled on non-ia64 archs

2012-12-30 Thread Stephan Schreiber

The goal should be to allow a parallel build on *all* archs. There  
shouldn't be any exception for ia64.


The entire ifneq construct should be removed:

ifneq ($(DEB_HOST_ARCH),ia64)
extra_dh_opts += --parallel
endif




The dh invoke should read:

dh $@ --parallel --with pkgkde_symbolshelper



Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#692053: ia64 Iceweasel 10.0 (and above?) randomly stops responding, eating 100% CPU

2012-12-23 Thread Stephan Schreiber

I can provide the built debs for ia64 (150MB) after making some room  
for it on my webspace:


http://fs-driver.org/debian-ia64/iceweasel-10.0.11esr-debs.tar

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642750: [PATCH] epiphany-browser: HIGHLY unstable on ia64, (IA-64/IPF/Itanium) platform

2012-12-22 Thread Stephan Schreiber


Gustavo Noronha Silva wrote:


Thanks for the patches! I will include them in my next upload, do you
mind proposing them upstream, though? I don't feel like I know enough of
this bit of the code to propose them myself.


Yes, I do - any assistance of you is appreciated.
I think, webkit 1.8.1 is an outdated version for the upstream; I would  
make more sense to make another patch for the most recent webkit 1.11.
Since there are some other difficult ia64 RC bugs to do and the  
porters are understaffed, I attempt to do it after the release of  
Wheezy.


Btw: It seems that fixing of epiphany/webkit isn't completed because  
it doesn't work satisfactory yet.


Regards
Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642750: [PATCH] epiphany-browser: HIGHLY unstable on ia64, (IA-64/IPF/Itanium) platform

2012-12-22 Thread Stephan Schreiber


Émeric Maschino wrote:


I used your patched packages the passed week for my homeworks.
Stability is far better than the first patchset. With the notable
exception of the Google homepage. I don't know what's going wrong and
if other URLs are also affected. Let me explain.

Opening Epiphany with a blank page as startup page, typing
www.google.com in the bar address and clicking on Enter briefly goes
to the Google homepage and Epiphany immediately crashes.


I couldn't reproduce the crash on the Google homepage.
But you are right: I experience it, too; Epiphany still crashes *sometimes*.

Obviously Epiphany/Webkit still has at least one more bug...




Let me know if additional tests are welcomed.


I think further tests at the level of a user wouldn't have any benefit  
at the moment.

(Please could you test the patches for Iceweasel 10.0.11esr at next?)

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696506: error on using a pch: had text segment at different address

2012-12-21 Thread Stephan Schreiber


Package: src:gcc-4.6
Version: 4.6.3-11
Severity: serious



The gcc/g++-compiler has a bug that prevents a precompiled header  
(pch) from being used. It occurred on all ia64 Debian buildds while  
building the qt4-x11 package. Bug#696096 is already filed for that.

The log reads:

g++ -c -include .pch/release-shared/QtCore -Winvalid-pch -g -O2  
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  
-I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0  
-I/usr/lib/ia64-linux-gnu/glib-2.0/include -O2 -fvisibility=hidden  
-fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED  
-DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII  
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT  
-DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\/lib/ld-linux-ia64.so.2\  
-DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT  
-DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE  
-I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore  
-I.rcc/release-shared -Iglobal -I../../tools/shared  
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4  
-I.moc/release-shared -o .obj/release-shared/qlibraryinfo.o  
global/qlibraryinfo.cpp
cc1plus: warning: ./.pch/release-shared/QtCore.gch/c: not for GNU C++  
[enabled by default]
cc1plus: warning: ./.pch/release-shared/QtCore.gch/c++: had text  
segment at different address [enabled by default]

cc1plus: error: one or more PCH files were found, but they were invalid
cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory
compilation terminated.


When you are using precompiled headers (pch), you invoke gcc/g++ at  
least twice. The first time to create the pch file - to write out the  
file. Second time to use the pch file - to read it in. Gcc expects  
that its binary image is always mapped at the same address in the  
virtual address space of the process. But when gcc's image is mapped  
to another address when reading in the pch than it was on writing out  
the pch, it reports the seen message.


The source code file src/gcc/c-family/c-pch.c of the src:gcc-4.6 gives  
more details:



/* Check the PCH file called NAME, open on FD, to see if it can be
   used in this compilation.  Return 1 if valid, 0 if the file can't
   be used now but might be if it's seen later in the compilation, and
   2 if this file could never be used in the compilation.  */

int
c_common_valid_pch (cpp_reader *pfile, const char *name, int fd)
{
...
  /* If the text segment was not loaded at the same address as it was
 when the PCH file was created, function pointers loaded from the
 PCH will not be valid.  We could in theory remap all the function
 pointers, but no support for that exists at present.
 Since we have the same executable, it should only be necessary to
 check one function.  */
  if (v.pch_init != pch_init)
{
  if (cpp_get_options (pfile)-warn_invalid_pch)
cpp_error (pfile, CPP_DL_WARNING,
   %s: had text segment at different address, name);
  return 2;
}

...
}


It is experienced on ia64 here, but the bug affects any arch.

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696096: qt4-x11 ia64 FTBFS only on the buildds

2012-12-17 Thread Stephan Schreiber

Just for the file; the tail of the most recent build log:

make[3]: Entering directory
`/build/buildd-qt4-x11_4.8.2+dfsg-5-ia64-2m8MNJ/qt4-x11-4.8.2+dfsg/src/corelib'
g++ -c -include .pch/release-shared/QtCore -Winvalid-pch -g -O2
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
-I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/ia64-linux-gnu/glib-2.0/include -O2 -fvisibility=hidden
-fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED
-DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\/lib/ld-linux-ia64.so.2\
-DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT
-DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
-I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore
-I.rcc/release-shared -Iglobal -I../../tools/shared
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -o .obj/release-shared/qlibraryinfo.o
global/qlibraryinfo.cpp
cc1plus: warning: ./.pch/release-shared/QtCore.gch/c: not for GNU C++
[enabled by default]
cc1plus: warning: ./.pch/release-shared/QtCore.gch/c++: had text
segment at different address [enabled by default]

cc1plus: error: one or more PCH files were found, but they were invalid
cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory
compilation terminated.
make[3]: *** [.obj/release-shared/qlibraryinfo.o] Error 1
make[3]: Leaving directory
`/build/buildd-qt4-x11_4.8.2+dfsg-5-ia64-2m8MNJ/qt4-x11-4.8.2+dfsg/src/corelib'

make[2]: *** [sub-corelib-install_subtargets-ordered] Error 2
make[2]: Leaving directory
`/build/buildd-qt4-x11_4.8.2+dfsg-5-ia64-2m8MNJ/qt4-x11-4.8.2+dfsg'
dh_auto_install: make -j1 install
DESTDIR=/build/buildd-qt4-x11_4.8.2+dfsg-5-ia64-2m8MNJ/qt4-x11-4.8.2+dfsg/debian/tmp AM_UPDATE_INFO_DIR=no INSTALL_ROOT=/build/buildd-qt4-x11_4.8.2+dfsg-5-ia64-2m8MNJ/qt4-x11-4.8.2+dfsg/debian/tmp/ returned exit code
2

make[1]: *** [override_dh_auto_install] Error 29
make[1]: Leaving directory
`/build/buildd-qt4-x11_4.8.2+dfsg-5-ia64-2m8MNJ/qt4-x11-4.8.2+dfsg'

make: *** [binary-arch] Error 2

The -Winvalid-pch switch provided the following info:

cc1plus: warning: ./.pch/release-shared/QtCore.gch/c: not for GNU C++
[enabled by default]

Correct and what one would expect.

cc1plus: warning: ./.pch/release-shared/QtCore.gch/c++: had text
segment at different address [enabled by default]

That's what I wanted to read.
I looked into the sources of gcc. When you are using precompiled
headers (pch), you invoke gcc/g++ at least twice. The first time to
create the pch file - to write out the file. Second time to use the
pch file - to read it in. Gcc expects that its binary image is always
mapped at the same address in the virtual address space of the
process. But when gcc's image is mapped to another address when
reading in the pch than it was on writing out the pch, it reports the
seen message.
This is a flaw of gcc, not of the qt4-x11 package. I can't explain why
the gcc binary is mapped to altering addresses on the buildd, but not
on any other used ia64 machine.

Lisandro Damián Nicanor Pérez Meyer wrote:

Searching the web I came across:

http://lists.gnu.org/archive/html/mingw-cross-env-list/2011-10/msg00016.html
http://lists.gnu.org/archive/html/mingw-cross-env-list/2011-10/msg00017.html

You have found someone else who had this problem - on MacOS. But they
did not find a good fix.

Lisandro Damián Nicanor Pérez Meyer wrote:

As it only FTBFS in the buildds but not on merulo, I took a look at
the versions of gcc: 4:4.6.3-7 on alkman and 4:4.6.3-8 inside the
unstable dchroot of merulo.

Stephan: what version of GCC did you use while you tried on your box?

Uum, I think it was 4:4.6.3-8.
But it doesn't matter; as already mentioned, I looked into gcc's
sources. Any gcc version since 2004 has exactly that behaviour.
Earlier versions simply crash.

So gcc needs a fix. Because we won't finish it in the next few days, I
suggest a tentative workaround on ia64.

Please could you take the most recent version 4:4.8.2+dfsg-5 of the
qt4-x11 package and make a new dfsg version for unstable again.
- Please could you revert the add-winvalid-pch.patch (of my previous
message) because the -Winvalid-pch switch is no longer needed.

- Please could you apply the attached patch tentative-no-pch-on-ia64.patch.

The patch disables the usage of precompiled headers on ia64. This will
slow down the build, but it will succeed; you can migrate your
security fixes to testing.

The patch doesn't change anything on archs other than ia64.

Please could you keep this bug report open; I'll file a new bug for
the gcc package shortly, which will block this bug.

After the problem with gcc is solved; you can revert the tentative workaround.

Regards
Stephan

Bug#696041: ia64 (Itanium) Mozilla JS engine needs pointers have their high 17 bits cleared

2012-12-16 Thread Stephan Schreiber


Package: iceweasel
Version: 10.0.11esr-1
Severity: serious
Tags: patch


Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G



The Mozilla JS engine needs pointers have their high 17 bits cleared  
because it would break a variant data type which the engine uses.
This bug is actually the same as we had for the Mozilla Spider Mokey  
JS engine library - libmozsjs185-1.0, bug#659186.
Mapping of pages should be patched. Furthermore, the memory for  
'static strings' must not be global static variables (text segment).


The code of Iceweasel is somewhat newer than the one of libmozjs185.  
It has slightly changed.


At first I had a patch which was very similar to the one of  
bug#659186. But disabling the static strings optimization of the js  
engine was a serious performance penalty that a lot of tests of the  
test suite timed out and failed. (Bug#692053 wasn't the reason for  
that.)


So I decided to keep the static strings optimization; the patch  
allocates mapped memory and puts the static strings into it upon  
startup on ia64. So any address of an item in the static strings array  
always have their high 17 bits cleared.


The patches don't change anything on archs other than ia64.

- Please apply 01-fix-map-pages-on-ia64.patch first.
- At next 02-static-str-in-mmem-on-ia64.patch.

You also need the patch of bug#692053.

Stephan



01-fix-map-pages-on-ia64.patch
Description: 01-fix-map-pages-on-ia64.patch


02-static-str-in-mmem-on-ia64.patch
Description: 02-static-str-in-mmem-on-ia64.patch

Bug#692053: [PATCH] ia64 Iceweasel 10.0 (and above?) randomly stops responding, eating 100% CPU

2012-12-16 Thread Stephan Schreiber


found 692053 10.0.11esr-1
notfound 692053 10.0~b2-1
# that version is over; nobody wants to patch it anymore, I guess
severity 692053 serious
tags 692053 + patch
thanks


I could reproduce the bug on Wheezy.

Iceweasel also needs a patch for the address range problem on ia64  
again since the upstream development has removed it in the meantime. I  
filed the separate bug#696041 for that.

After applying the patch of bug#696041, Iceweasel still used to hang.

It turned out that the garbage collector has two bugs that can cause  
an endless loop.


The problem is in js/src/jsgc.cpp:2385 in the function DecommitFreePages():

static void
DecommitFreePages(JSContext *cx)
{
JSRuntime *rt = cx-runtime;

for (GCChunkSet::Range r(rt-gcChunkSet.all()); !r.empty();  
r.popFront()) {

Chunk *chunk = r.front();
while (chunk) {
ArenaHeader *aheader =  
static_castArenaHeader*(chunk-info.freeArenasHead);


/*
 * In the non-failure case, the list will be gone at the end of
 * the loop. In the case where we fail, we relink all failed
 * decommits into a new list on freeArenasHead.
 */
chunk-info.freeArenasHead = NULL;

while (aheader) {
/* Store aside everything we will need after decommit. */
ArenaHeader *next = aheader-next;

bool success = DecommitMemory(aheader, ArenaSize);
if (!success) {
aheader-next = chunk-info.freeArenasHead;
chunk-info.freeArenasHead = aheader;
continue;
}

size_t arenaOffset =  
Chunk::arenaIndex(reinterpret_castuintptr_t(aheader));

chunk-decommittedArenas.set(arenaOffset);
--chunk-info.numArenasFreeCommitted;
--rt-gcNumFreeArenas;

aheader = next;
}

chunk = chunk-info.next;
}
}
}


This code calls a function DecommitMemory(); ArenaSize is constant  
4096, defined in js/src/jsgc.h:


const size_t ArenaShift = 12;
const size_t ArenaSize = size_t(1)  ArenaShift;
const size_t ArenaMask = ArenaSize - 1;

The DecommitMemory() is in js/src/jsgcchunk.cpp:

bool
DecommitMemory(void *addr, size_t size)
{
JS_ASSERT(uintptr_t(addr) % 4096UL == 0);
int result = madvise(addr, size, MADV_DONTNEED);
return result != -1;
}




When I debugged the hanging Iceweasel, a thread was in the most inner  
while loop in DecommitFreePages()


ArenaHeader *aheader =  
static_castArenaHeader*(chunk-info.freeArenasHead);


/*
 * In the non-failure case, the list will be gone at the end of
 * the loop. In the case where we fail, we relink all failed
 * decommits into a new list on freeArenasHead.
 */
chunk-info.freeArenasHead = NULL;

while (aheader) {
/* Store aside everything we will need after decommit. */
ArenaHeader *next = aheader-next;

bool success = DecommitMemory(aheader, ArenaSize);
if (!success) {
aheader-next = chunk-info.freeArenasHead;
chunk-info.freeArenasHead = aheader;
continue;
}

size_t arenaOffset =  
Chunk::arenaIndex(reinterpret_castuintptr_t(aheader));

chunk-decommittedArenas.set(arenaOffset);
--chunk-info.numArenasFreeCommitted;
--rt-gcNumFreeArenas;

aheader = next;
}

aheader was always 0x70011e0100 on each loop iteration since  
aheader-next was 0x70011e0100, too.

The question was how this state could occur.

Assume that we are in the first iteration of the loop. aheader is  
initialized with the ptr of chunk-info.freeArenasHead.
DecommitMemory is called, for example, with the address 0x70011e0100  
and the size 4096 (which is ArenaSize).
DecommitMemory() will fail since madvise() requires a page aligned  
addr and length


int madvise(void *addr, size_t length, int advice);

(madvise() returns the EINVAL error code.)

Neither the seen address 0x70011e0100 nor the length 4096 is page  
aligned here. Remember that Linux on ia64 can have 4K, 8K, 16K, or 64K  
page dependant on the configuration the Kernel was compiled with.  
Debian uses 16K on ia64.

So the subsequent if statement executes its body:

if (!success) {
aheader-next = chunk-info.freeArenasHead;
chunk-info.freeArenasHead = aheader;
continue;
}

Here happens what the above comment explains: ...we relink all failed  
decommits into a new list on freeArenasHead..
aheader is inserted as the new head item in the singly linked list  
which starts with chunk-info.freeArenasHead. Please note that  
chunk-info.freeArenasHead has been cleared above

Bug#696096: qt4-x11 ia64 FTBFS only on the buildds

2012-12-16 Thread Stephan Schreiber


Package: src:qt4-x11
Version: 4:4.8.2+dfsg-4
Severity: important
Tags: moreinfo




Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com
wrote to debian-i...@lists.debian.org, i...@buildd.debian.org,  
pkg-kde-t...@lists.alioth.debian.org

on Sat, 8 Dec 2012 21:33:30 -0300:

Please keep pkg-kde-t...@lists.alioth.debian.org CCed, we are not  
subscribed to this lists. Thanks!


Hi ia64 porters/buildd maintainers! I'm writing you because of the  
strange FTBFS we have for qt4-x11 [0], which are normally solved by  
doing a give-back until it builds :-/ .


It's not the first time we see this, and as in other ocassions, we  
have accessed a porter machine (merulo.debian.org) to try to  
determine what's going on. Saddly all we could do is sucessfully  
build the packages. We could not reproduce the bug in any way :-(


This last time Pino Toscano tried three times and one myself. You  
can get the compressed log from my build from [1].


I would like to know if there is something else we/you can try to  
solve this issue. Maybe it only triggers inside sbuild?


This is the only issue that keeps some security fixes of Qt out of  
wheezy, and so it would be really great if we can find a way to  
solve this FTBFS.


[0] https://buildd.debian.org/status/logs.php?pkg=qt4-x11arch=ia64
[1] http://perezmeyer.com.ar/temp/qt4_x11_buildlog.txt.xz


--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/




The tail of the most recent build log:

cd src/corelib/  make -f Makefile install
make[3]: Entering directory  
`/build/buildd-qt4-x11_4.8.2+dfsg-4-ia64-CRoDdA/qt4-x11-4.8.2+dfsg/src/corelib'
g++ -c -include .pch/release-shared/QtCore -g -O2 -Wformat  
-Werror=format-security -D_FORTIFY_SOURCE=2 -I/usr/include/freetype2  
-pthread -I/usr/include/glib-2.0  
-I/usr/lib/ia64-linux-gnu/glib-2.0/include -O2 -fvisibility=hidden  
-fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED  
-DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII  
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT  
-DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\/lib/ld-linux-ia64.so.2\  
-DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT  
-DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE  
-I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore  
-I.rcc/release-shared -Iglobal -I../../tools/shared  
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4  
-I.moc/release-shared -o .obj/release-shared/qlibraryinfo.o  
global/qlibraryinfo.cpp

cc1plus: error: one or more PCH files were found, but they were invalid
cc1plus: error: use -Winvalid-pch for more information
cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory
compilation terminated.
make[3]: *** [.obj/release-shared/qlibraryinfo.o] Error 1
make[3]: Leaving directory  
`/build/buildd-qt4-x11_4.8.2+dfsg-4-ia64-CRoDdA/qt4-x11-4.8.2+dfsg/src/corelib'

make[2]: *** [sub-corelib-install_subtargets-ordered] Error 2
make[2]: Leaving directory  
`/build/buildd-qt4-x11_4.8.2+dfsg-4-ia64-CRoDdA/qt4-x11-4.8.2+dfsg'
dh_auto_install: make -j1 install  
DESTDIR=/build/buildd-qt4-x11_4.8.2+dfsg-4-ia64-CRoDdA/qt4-x11-4.8.2+dfsg/debian/tmp AM_UPDATE_INFO_DIR=no INSTALL_ROOT=/build/buildd-qt4-x11_4.8.2+dfsg-4-ia64-CRoDdA/qt4-x11-4.8.2+dfsg/debian/tmp/ returned exit code  
2

make[1]: *** [override_dh_auto_install] Error 29
make[1]: Leaving directory  
`/build/buildd-qt4-x11_4.8.2+dfsg-4-ia64-CRoDdA/qt4-x11-4.8.2+dfsg'

make: *** [binary-arch] Error 2




I couldn't figure out yet what is really going on with the package on  
the buildds, and why g++ refuses the precompiled header file (pch).

It builds fine on my box.

Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G


I suggest doing the following:
- Please could you make a new dfsg version of the qt4-x11 package for  
unstable. Please apply both attached patches.
- The patches won't fix the problem, but we'll get a more verbose  
error message when it fails next time on the buildd.


The patch revert_ia64-remove-parallel.patch reverts the removal of the  
dh --parallel switch on ia64 which you have done with version  
4:4.7.4-1 a year ago.
The patch add-winvalid-pch.patch adds the -Winvalid-pch switch to any  
g++ and gcc invocation that uses a pch file. This should give us the  
reason why the compiler doesn't recognize the pch.


This shouldn't have any side effect to the other archs than ia64.

I'll watch out the buildd log of the next dfsg version of the package.

Stephan




revert-ia64-remove-parallel.patch
Description: revert-ia64-remove-parallel.patch


add-winvalid-pch.patch
Description: add-winvalid-pch.patch

Bug#642750: [PATCH] epiphany-browser: HIGHLY unstable on ia64, (IA-64/IPF/Itanium) platform

2012-12-07 Thread Stephan Schreiber


Émeric Maschino wrote:


Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report


I looked for anything that is different on a release build and on a  
debug build. It turned out that a lot of code related to the memory  
heap is different in Source/JavaScriptCore/wtf/FastMalloc.cpp:


#if !(defined(USE_SYSTEM_MALLOC)  USE_SYSTEM_MALLOC)  defined(NDEBUG)
#define FORCE_SYSTEM_MALLOC 0
#else
#define FORCE_SYSTEM_MALLOC 1
#endif

(Consider NDEBUG.)

Webkit doesn't use its own heap implementation in FastMalloc.cpp on  
the debug build! When someone builds the release build all the buggy  
code runs and will make trouble.
This was done to make debugging much easier :-). (Greetings from  
Google's sadists club.)


I didn't try to find all bugs in the fast malloc implementation. One  
thing I noticed which could break it on ia64 but works on x86-64 is  
the following in Source/JavaScriptCore/wtf/FastMalloc.cpp:1375:


  // Return 0 if we have no information, or else the correct sizeclass for p.
  // Reads and writes to pagemap_cache_ do not require locking.
  // The entries are 64 bits on 64-bit hardware and 16 bits on
  // 32-bit hardware, and we don't mind raciness as long as each read of
  // an entry yields a valid entry, not a partially updated entry.
  size_t GetSizeClassIfCached(PageID p) const {
return pagemap_cache_.GetOrDefault(p, 0);
  }
  void CacheSizeClass(PageID p, size_t cl) const {  
pagemap_cache_.Put(p, cl); }




When different processor cores access one memory location - one  
processor at first, the second one at next - the processor cores  
excange the data through their caches as needed with their bus  
protocol automatically on x86 and x86-64.
But on ia64 caches are not coherent automatically, the caches are  
flushed using memory barriers (some special machine instructions).
When you use some dispatcher objects, for example, a mutex with the  
following pattern

- acquire the dispatcher object
- read/write to the data location which are guarded by the dispatcher object,
- release the dispatcher object
you don't need to think on the cache coherency and memory barriers.  
The implementation of the dispatcher object does the memory barriers  
correctly for you.


When you start to do something own what has multiple threads but  
doesn't use any dispatcher object, you have to think on memory  
barriers. Ia64 isn't the only arch that requires this.




One approach would be building-in the needed memory barrier in  
FastMalloc.cpp. This would mean adding memory barrier definitions for  
a lot of architectures. You can take a look at the  
hw/xfree86/common/compiler.h file of the xserver-xorg-core package in  
order to get an idea what it would mean.
So the second approach: We do no longer use the fast malloc  
implementation on ia64 as it is already done on Blackberry OS and on  
the Qt port of webkit on any OS other than UNIX.


An appropriate modification can be useful as well on other archs that  
require memory barriers, for example, alpha, powerpc.


So here is a new set of patches:
01-ia64-wide-ptr.patch at first,
02-ia64-use-system-malloc.patch at next.

The patches are for the most recent libwebkitgtk-3.0-0 package of Wheezy.
The patches don't change anything on archs other than ia64.


The packages which were built with the patch of this bug report and  
the one of bug#694971 are here; the tar contains all debs which are  
created by the libwebkitgtk-3.0-0 source:

http://www.fs-driver.org/debian-ia64/webkitgtk-debs-v2.tar


The patches also fix bug#582774 (seed FTBFS on ia64).

Stephan



01-ia64-wide-ptr.patch
Description: 01-ia64-wide-ptr.patch


02-ia64-use-system-malloc.patch
Description: 02-ia64-use-system-malloc.patch

Bug#593141: Bug#653582: ruby-hpricot: FTBFS on ia64: ruby crashes while running tests

2012-12-07 Thread Stephan Schreiber


I took a look at this a few weeks ago.

The problem is the code in the cont.c file which implements continuations.
A thread saves its own stack and its thread context itself while it is  
running. The ruby programmers believe that that the saved info can be  
used by another thread to switch over. They are wrong!
This is simply ill-formed code; wrong usage of the  
makecontext()/swapcontext() functions. It is a miracle that it works  
on other architectures - on sparc it did after doing some dirty tricks.
The problem causes crashes which are almost impossible to understand  
with the debugger.
The code was written in 2007 and made a lot of trouble until now; when  
you take a look to cont.c, you are see some really weird code  
fragments - dirty hacks to workaround some fundamental design flaws.
I'm not satisfied with the code quality of the ruby project at all; I  
don't understand how it could be included in a ruby version that is  
for production use.


So the continuations and perhaps some related threading features are  
broken - very advanced and new features in Ruby.


I think a fix is feasable for platforms which use  
makecontext()/swapcontext() - as Linux is (rather than Windows Win32  
functions).


What can be implememnted is that a thread switches to another  
context/stack; the initial context/stack is saved after that. The  
thread switches back to the initial context/stack finally.

This means:
- The performance becomes worse due to additional context switches. I  
think it isn't that bad; the ruby code copies over huge portions of  
memory in its implementation all the time; the entire original code is  
a huge performance penalty (if it wouldn't crash). I don't believe  
that the additional context switches makes it noticeable worse.
- The patch would be a real patch bomb. It would remove a lot of mess  
for (not working) ia64 workarounds and the most recent sparc patches  
of Debian as well. The patch replaces a lot of code of cont.c.
- The patch would change the implementation for all Debian archs, not  
only ia64.


I appreciate comments on that.
For now I'd prefer the 'wheezy-ignore' rather than removing the ia64  
ruby package.


Stephan


If you want to read something pleasing about ia64 for a change, you  
can take a look at bug#659186 or #582774.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642750: [PATCH] epiphany-browser: HIGHLY unstable on ia64, (IA-64/IPF/Itanium) platform

2012-12-04 Thread Stephan Schreiber


Peter Green wrote:



 The proposed patch defines a third option
 USE(JSVALUE64W)
 which we use *only* on ia64.
 It uses an encapsulated union without any trick for the variant  
data   type. This is portable but

 - the data type is 128-bits wide,
 - Enabling JIT compiler isn't possible - that's not that bad; ia64  
  doesn't have a JIT compiler.
   Is the type in question purely internal to webkit or is it also  
used by client applications? If the latter then presumablly a soname  
bump and hence a transition would be needed.



The type is internal. Exported are only opaque pointer types.
Because I wasn't really sure, I diff'd the contents of
 libjavascriptcoregtk-3.0-dev_1.8.1-3.3_ia64.deb and
 libwebkitgtk-3.0-dev_1.8.1-3.3_ia64.deb
which were created with and without the patches.

Different were only some mysteric id in included html documentation  
files and the Debian/md5sums file.

All included .h files were identical.
The patches do not change the binary interface.

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642750: [PATCH] epiphany-browser: HIGHLY unstable on ia64 (IA-64/IPF/Itanium) platform

2012-12-04 Thread Stephan Schreiber


Émeric Maschino wrote:


Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report


Hmm, the webkit thing seems to have at least yet another bug :-(. The  
bug doesn't occur on my most recent debug build of libwebkitgtk-3.0-0.
But I could reproduce the crash several times today with the release  
build. The crash was on different code locations and with completely  
different stack traces.

Further research is needed here...



And unfortunately, trying to get an informative stacktrace in gdb, I'm
now hitting the SIGTRAP issue [2] :-(


I don't believe that we would have much benefit of any stack trace on  
this bug.
I'm still using the Kernel 3.2.23 with the futex patch [2] compiled  
with GCC4.4. Yet another ia64 problem.


Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694971: ia64 (Itanium) Epiphany browser crashes within JSC::JSArray::increaseVectorLength()

2012-12-02 Thread Stephan Schreiber


Package: libwebkitgtk-3.0-0
Version: 1.8.1-3.3
Severity: grave
Tags: patch


Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G



I realized this bug while working on bug#642750.

The Epiphany browser crashed with a SIGSEGV in  
JSC::JSArray::increaseVectorLength()


I built the libwebkitgtk-3.0-0 package which was configured with  
--enable-debug.
Furthermore, I modified the Source/JavaScriptCore/wtf/Assertions.h in  
order to be able to continue subsequent to a failed assertion; I  
defined CRASH() to expand to nothing.




bool JSArray::increaseVectorLength(JSGlobalData globalData, unsigned  
newLength)

{
// This function leaves the array in an internally inconsistent  
state, because it does not move any values from sparse value map
// to the vector. Callers have to account for that, because they  
can do it more efficiently.

if (newLength  MAX_STORAGE_VECTOR_LENGTH)
return false;

ArrayStorage* storage = m_storage;

unsigned vectorLength = m_vectorLength;
ASSERT(newLength  vectorLength);
unsigned newVectorLength = getNewVectorLength(newLength);

// Fast case - there is no precapacity. In these cases a realloc  
makes sense.

if (LIKELY(!m_indexBias)) {
void* newStorage = storage-m_allocBase;
if (!globalData.heap.tryReallocateStorage(newStorage,  
storageSize(vectorLength), storageSize(newVectorLength)))

return false;

storage = m_storage =  
reinterpret_cast_ptrArrayStorage*(static_castchar*(newStorage));

m_storage-m_allocBase = newStorage;
ASSERT(m_storage-m_allocBase);

WriteBarrierUnknown* vector = storage-m_vector;
for (unsigned i = vectorLength; i  newVectorLength; ++i)
vector[i].clear();=== here the  
crash occurs


m_vectorLength = newVectorLength;

return true;
}


It turned out that tryReallocateStorage() allocated a memory block  
that is smaller than requested with the last parameter of the function.
When it occured, the requested size was quite large and the code of  
the following function was executed  
(Source/JavaScriptCore/heap/CopiedSpaceInlineMethods.h):


inline CheckedBoolean CopiedSpace::tryAllocateOversize(size_t bytes,  
void** outPtr)

{
ASSERT(isOversize(bytes));

size_t blockSize =  
WTF::roundUpToMultipleOfs_pageSize(sizeof(CopiedBlock) + bytes);
PageAllocationAligned allocation =  
PageAllocationAligned::allocate(blockSize, s_pageSize,  
OSAllocator::JSGCHeapPages);

if (!static_castbool(allocation)) {
*outPtr = 0;
return false;
}

}

WTF::roundUpToMultipleOfs_pageSize() rounded up the requested size  
to a multiple of 4K. s_pageSize is a constant which is defined in the  
CopiedSpace class (Source/JavaScriptCore/heap/CopiedSpace.h)


static const size_t s_pageSize = 4 * KB;


At next PageAllocationAligned::allocate() is called  
(Source/JavaScriptCore/wtf/PageAllocationAligned.cpp):


PageAllocationAligned PageAllocationAligned::allocate(size_t size,  
size_t alignment, OSAllocator::Usage usage, bool writable, bool  
executable)

{
ASSERT(isPageAligned(size));
ASSERT(isPageAligned(alignment));
ASSERT(isPowerOfTwo(alignment));
ASSERT(size = alignment);
size_t alignmentMask = alignment - 1;

#if OS(DARWIN)

#else
size_t alignmentDelta = alignment - pageSize();

// Resererve with suffcient additional VM to correctly align.
size_t reservationSize = size + alignmentDelta;
void* reservationBase =  
OSAllocator::reserveUncommitted(reservationSize, usage, writable,  
executable);


// Select an aligned region within the reservation and commit.
void* alignedBase = reinterpret_castuintptr_t(reservationBase)  
 alignmentMask
?  
reinterpret_castvoid*((reinterpret_castuintptr_t(reservationBase)  
 ~alignmentMask) + alignment)

: reservationBase;
OSAllocator::commit(alignedBase, size, writable, executable);

return PageAllocationAligned(alignedBase, size, reservationBase,  
reservationSize);

#endif
}


The first two assertions failed:
ASSERT(isPageAligned(size));
ASSERT(isPageAligned(alignment));

The alignmentDelta variable is a 64-bits unsigned integer and  
evaluated to a value of 18446744073709539328 (which is 2^64 - 12288 )  
because at the line


size_t alignmentDelta = alignment - pageSize();

the 'alignment' arg is 4096 and 'pageSize()' returned 16384 - we'll  
take a closer look on the latter one below.

The subsequent line

size_t reservationSize = size + alignmentDelta;

evaluated the reservationSize var to an integer value less than size  
because the 64-bits integer arithmetics overflowed and wrapped around.

This is the reason why the allocated memory block was too small.

The mentioned pageSize() function returned the actual page size of  
16K, which is correct.
Linux on ia64 can have 4K, 8K, 16K, or 64K page dependant on the

Bug#642750: [PATCH] epiphany-browser: HIGHLY unstable on ia64 (IA-64/IPF/Itanium) platform

2012-12-02 Thread Stephan Schreiber


severity 642750 grave
tags 642750 + patch
block 582774 by 642750
thanks



While working on this bug I realized that webkit has yet another bug  
that prevents it from working on ia64. I filed the separate bug#694971  
for that.


I built the libwebkitgtk-3.0-0 package which was configured with  
--enable-debug. (Wasn't possible with the initial 4GB of memory at  
all. After a memory upgrade to 16GB it took eleven-and-a-half hour on  
my box with the -j2 option.)


Just starting epiphany-browser showed a first hint what is going on:
ASSERTION FAILED: isCell()
../Source/JavaScriptCore/runtime/JSValueInlineMethods.h(491) :  
JSC::JSCell* JSC::JSValue::asCell() const


Webkit uses a variant data type JSValue, which it uses for anything  
that can be a thing on Java script. It can contain an integer number,  
a float number or a pointer to an object - this is 'cell'.


It turned out that the 'isCell()' assertion failed for a JSValue that  
just has been initialized as a pointer.


The arch determines how the JSValue is defined; there are two options  
(yet), one for any 32-bits arch, the other one for 64-bits archs.


You can see this in Source/JavaScriptCore/runtime/JSValue.h - JSValue  
defines an embedded data type 'EncodedValueDescriptor' for that:


#if USE(JSVALUE32_64)
typedef int64_t EncodedJSValue;
#else
typedef void* EncodedJSValue;
#endif

union EncodedValueDescriptor {
int64_t asInt64;
#if USE(JSVALUE32_64)
double asDouble;
#elif USE(JSVALUE64)
JSCell* ptr;
#endif

#if CPU(BIG_ENDIAN)
struct {
int32_t tag;
int32_t payload;
} asBits;
#else
struct {
int32_t payload;
int32_t tag;
} asBits;
#endif
};



#if USE(JSVALUE32_64)
/*
 * On 32-bit platforms USE(JSVALUE32_64) should be defined,  
and we use a NaN-encoded

 * form for immediates.
 *
 * The encoding makes use of unused NaN space in the IEEE754  
representation.  Any value
 * with the top 13 bits set represents a QNaN (with the sign  
bit set).  QNaN values
 * can encode a 51-bit payload.  Hardware produced and  
C-library payloads typically
 * have a payload of zero.  We assume that non-zero payloads  
are available to encode
 * pointer and integer values.  Since any 64-bit bit pattern  
where the top 15 bits are
 * all set represents a NaN with a non-zero payload, we can  
use this space in the NaN
 * ranges to encode other values (however there are also  
other ranges of NaN space that

 * could have been selected).
 *
 * For JSValues that do not contain a double value, the high  
32 bits contain the tag
 * values listed in the enums below, which all correspond to  
NaN-space. In the case of
 * cell, integer and bool values the lower 32 bits (the  
'payload') contain the pointer
 * integer or boolean value; in the case of all other tags  
the payload is 0.

 */
enum { Int32Tag =0x };
enum { BooleanTag =  0xfffe };
enum { NullTag = 0xfffd };
enum { UndefinedTag =0xfffc };
enum { CellTag = 0xfffb };
enum { EmptyValueTag =   0xfffa };
enum { DeletedValueTag = 0xfff9 };

enum { LowestTag =  DeletedValueTag };

uint32_t tag() const;
int32_t payload() const;
#elif USE(JSVALUE64)
/*
 * On 64-bit platforms USE(JSVALUE64) should be defined, and  
we use a NaN-encoded

 * form for immediates.
 *
 * The encoding makes use of unused NaN space in the IEEE754  
representation.  Any value
 * with the top 13 bits set represents a QNaN (with the sign  
bit set).  QNaN values
 * can encode a 51-bit payload.  Hardware produced and  
C-library payloads typically
 * have a payload of zero.  We assume that non-zero payloads  
are available to encode
 * pointer and integer values.  Since any 64-bit bit pattern  
where the top 15 bits are
 * all set represents a NaN with a non-zero payload, we can  
use this space in the NaN
 * ranges to encode other values (however there are also  
other ranges of NaN space that

 * could have been selected).
 *
 * This range of NaN space is represented by 64-bit numbers  
begining with the 16-bit
 * hex patterns 0xFFFE and 0x - we rely on the fact that  
no valid double-precision

 * numbers will begin fall in these ranges.
 *
 * The top 16-bits denote the type of the encoded JSValue:
 *
 * Pointer {  :::
 *  / 0001:::
 * Double  { ...
 *  \ FFFE:::
 * Integer {  :::
 *
 * The scheme we have implemented encodes double

Bug#582774: seed FTBFS on ia64

2012-12-02 Thread Stephan Schreiber


severity 582774 serious
tags 582774 - help
thanks



The seed package suffers from two bugs of webkit:
bug#642750 (epiphany-browser: *HIGHLY* unstable on ia64  
(IA-64/IPF/Itanium) platform)
bug#694971 (ia64 (Itanium) Epiphany browser crashes within  
JSC::JSArray::increaseVectorLength())


I can confirm that the most recent seed package on Wheezy no longer  
FTBS on ia64 after the webkit package with the patches of bug#642750  
and bug#694971 has been installed.


So all you need to do here is waiting until the mentioned bugs are  
done, and add seed for ia64 on the FTP again.


Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

2012-10-31 Thread Stephan Schreiber

I tried some older Kernel versions in order to get more information  
about the regression.


Udeb and libudeb0 have been downgraded to version 161 in order to run  
older Kernels.



Kernel 3.0.0-2 (linux-image-3.0.0-2-mckinley_3.0.0-5_ia64.deb)
GDB 7.4.1 works

Kernel 3.1.0-rc7  
(linux-image-3.1.0-rc7-mckinley_3.1.0~rc7-1~experimental.1_ia64.deb)

GDB 7.4.1 works

Kernel 3.1.0-1 (linux-image-3.1.0-1-mckinley_3.1.1-1_ia64.deb)
GDB 7.4.1 doesn't work

Kernel 3.1.0-1 (linux-image-3.1.0-1-mckinley_3.1.4-1_ia64.deb)
GDB 7.4.1 doesn't work


If you read the changelog of linux-2.6, you realize that one  
difference between 3.1.0~rc7-1 and 3.1.1-1 is the used the GCC  
version: a change from 4.5 to 4.6.


This also explains the working Gentoo Kernel 3.3.8; it has been  
compiles with GCC 4.5.3.


I focused the Kernel 3.2.23 for the subsequent tests because it is the  
one in Wheezy. (Udev and libudev upgraded to the most recent versions  
in Wheezy.)


As you remember GDB 7.4.1 doesn't work on Kernel 3.2.23 - compiled  
with GCC 4.6.


I build Kernel 3.2.23 with GCC4.4. GDB 7.4.1 works on that Kernel! But  
don't be too excited, the bad news is coming soon.


That's quite interesting. Either a problem in some GCC versions or we  
have some source code in the Kernel which isn't portable in some way.


Emeric Maschine gave me the valuable hint on the Debian ia64 list that  
he have already seen some GDB trouble after a particular upstream  
patch in Kernel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=37a9d912b24f

The result was Debian bug#659485  
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659485) and an  
upstream patch (https://bugzilla.kernel.org/show_bug.cgi?id=42757):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c76f39bddb84f93f70a5520d9253ec0317bec216


The source code which was modified by these patches attracted my  
attention immediately.
Here is the source code of Kernel 3.2.23; the register operand  
constraints of the assembly block are *wrong*.


File arch/ia64/include/asm/futex.h:

static inline int
futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
  u32 oldval, u32 newval)
{
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;

{
register unsigned long r8 __asm (r8);
unsigned long prev;
__asm__ __volatile__(
  mf;;\n
  mov %0=r0   \n
  mov ar.ccv=%4;; \n
[1:]  cmpxchg4.acq %1=[%2],%3,ar.ccv  \n
  .xdata4 \__ex_table\, 1b-., 2f-.\n
[2:]
: =r (r8), =r (prev)
: r (uaddr), r (newval),
  rO ((long) (unsigned) oldval)
: memory);
*uval = prev;
return r8;
}
}



The list of output registers is
: =r (r8), =r (prev)
The constraint =r means that the GCC has to maintain that these vars  
are in registers and contain valid info when the program flow leaves  
the assembly block (output registers).
But =r also means that GCC can put them in registers that are used  
as input registers. Input registers are uaddr, newval, oldval on the  
example.

The second assembly instruction
  mov %0=r0   \n
is the first one which writes to a register; it sets %0 to 0. %0 means  
the first register operand; it is r8 here. (The r0 is read-only and  
always 0 on the Itanium; it can be used if an immediate zero value is  
needed.)
This instruction might overwrite one of the other registers which are  
still needed.
Whether it really happens depends on how GCC decides what registers it  
uses and how it optimizes the code.


The objdump utility can give us disassembly.
The futex_atomic_cmpxchg_inatomic() function is inline, so we have to  
look for a module that uses the funtion. This is the  
cmpxchg_futex_value_locked() function in

kernel/futex.c:

static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr,
  u32 uval, u32 newval)
{
int ret;

pagefault_disable();
ret = futex_atomic_cmpxchg_inatomic(curval, uaddr, uval, newval);
pagefault_enable();

return ret;
}


Now the dissembly. At first from the Kernel package 3.2.23 which has  
been compiled with GCC 4.4, remeber this Kernel seemed to work:

objdump -d linux-3.2.23/debian/build/build_ia64_none_mckinley/kernel/futex.o

0230 cmpxchg_futex_value_locked:
 230:   0b 18 80 1b 18 21   [MMI]   adds r3=3168,r13;;
 236:   80 40 0d 00 42 00   adds r8=40,r3
 23c:   00 00 04 00

Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

2012-10-27 Thread Stephan Schreiber


Package: gdb
Version: 7.4.1
Severity: serious


Dell PowerEdge 3250
2x Itanium Madison 1.5GHz 6M
4GB RAM


I realized that GDB doesn't work as it should.
When GDB should run *any* target application, it always stops with  
SIGTRAP 0x.

Example:


stephan@itanic:~$ gdb man
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as ia64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/man...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/man

Program received signal SIGTRAP, Trace/breakpoint trap.
0x in ?? ()
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x in ?? ()
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x in ?? ()
(gdb)



Debian Wheezy: Kernel 3.2.23, GDB 7.4.1 doesn't work
Debian Wheezy: Kernel 3.2.23, GDB 7.3 doesn't work
Debian Wheezy: with Kernel 3.5.5 (experimental), GDB 7.4.1 doesn't work
Debian Wheezy: with Kernel 3.5.5 (experimental), GDB 7.3 doesn't work
Debian Lenny:  Kernel 2.6.26, a 'debootstrapped' Wheezy userland, GDB  
7.4.1 *works*

Gentoo:Kernel 3.3.8,  GDB 7.3.1 works

I'm surprised that GDB 7.4.1 works on Lenny in the chroot'd Wheezy  
environment.

Please also note that the problem doesn't occur on Gentoo ia64.

In my opinion, it points to the Debian Kernel somehow...

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#659186: Debian bug 659186, new patch, ia64 libmozjs185

2012-10-20 Thread Stephan Schreiber


Émeric Maschino wrote:


Patched libmozjs185 [1] didn't solve the issue, though GNOME Shell
crashes in a slightly different way.
...
In this case, perhaps the second part
of the fix is also missing. Indeed, looking at the original bug report
again [4], it appears that JS engine breakage on ia64 was solved
thanks to jemalloc patch [3], but also by allowing to turn off static
JS strings allocation on ia64 [5]. Do these changes also need to be
ported/refactored to the (supposed) new JS code?


Yes, you are right. The static-js-string-patch is needed. I missed this.

Here is a new attempt, a set of two patches for libmozjs185 in wheezy.

The built package can be downloaded here:
http://www.fs-driver.org/debian-ia64/libmozjs185-1.0_1.8.5-1.0.0+dfsg-3.1_ia64-patchv2.deb

Unfortunately I can't test whether it works or not.

Stephan



je-malloc.patch
Description: je-malloc.patch


static-str.patch
Description: static-str.patch

Bug#685186: IA64 (Itanium) Wheezy, ELILO installation failed, patch proposal

2012-10-16 Thread Stephan Schreiber



Jonathan Nieder wrote:


So the next step is either to convince Debian's kernel maintainers
that it is worth including that module in the installer, or the elilo
maintainers that debian/elilo.sh should not use iocharset=iso8859-1,
or both.


Life is hard, I can tell you. I hoped you would do it voluntary :-).
What I want you to do isn't a big thing. Just to allow something,  
which is possible with the Debian kernel, also in the d-i.



Ben Hutchings wrote:


None of this is particularly relevant to the EFI boot volume, though,
as all filenames on there should be ASCII-only.


You are right. It doesn't really matter how this bug is fixed.

Unfortunately there isn't any message of the elilo maintainer yet.


Jonathan Nieder wrote:


In general, for what it's worth I disagree about that, but I wouldn't
be surprised if there are other considerations in this particular case
(if so, what are they?).


It seems that you have already decided how the bug will be fixed.

If you really want a change of elilo.sh, please could *you* do that (nmu).
There wasn'a any activity on the elilo package for months...

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685186: IA64 (Itanium) Wheezy, ELILO installation failed, patch proposal

2012-10-09 Thread Stephan Schreiber


I'm surprised that I could shock you with the severity level :-).

The bug prevents the script from installing ELILO on the EFI System  
partition (ESP) when a user attempts to install Debian with a Debian  
installation CD or DVD.
The user won't be able to workaround this on an opened console if he  
isn't very familiar how to install ELILO manually including writing  
the appropriate ELILO configuration.

The bug occurs *always*.
The bug occurs on *any* ia64 machine.
With this bug the Debian installer won't bring up a bootable system.
What means: it renders *any* ia64 Debian installation CD or DVD useless.
Actually you can stop building ia64 iso images unless this bug is fixed!

So what severity level is the right one for that?
Debian's Information regarding the bug processing system for package  
maintainers and bug triagers [1] states:


grave
makes the package in question unusable or mostly so, or causes  
data loss, or introduces a security hole allowing access to the  
accounts of users who use the package.


I think makes the package in question unusable is true for this bug.

The severity what you suggest is:

important
a bug which has a major effect on the usability of a package,  
without rendering it completely unusable to everyone.


This is not true for the bug. This wouldn't be a release critical bug either.
My conclusion is that the bug should be a release critical one because  
it renders the ia64 iso images useless for everyone: Grave.





The problen is that the debian/elilo.sh script fails to mount the  
(FAT) EFI System partition (ESP) because the nls_iso8859-1.ko module  
is absend.

The question is what package we can blame for that:

1. kernel-image-3.2.0-3-itanium-di
It builds two kernel images (Itanium, McKinley) and some udebs which  
are needed for the Debian installer. The  
fat-modules-3.2.0-3-itanium-di_3.2.23-1_ia64.udeb is one of them.


2. elilo
The mentioned debian/elilo.sh belongs to this package.


In my opinion you can say that the  
fat-modules-3.2.0-3-itanium-di_3.2.23-1_ia64.udeb lacks the  
nls_iso8859-1 module, so debian/elilo.sh is not able to do its work.
Since fat-modules-3.2.0-3-itanium-di_3.2.23-1_ia64.udeb is build by  
the kernel-image-3.2.0-3-itanium-di package, the bug should be  
assigned here.




Julien Cristau wrote:

 bwh 'iocharset=iso8859-1' is a bug; Linux standard character encoding
   is UTF-8
 bwh for filenames, at least
 bwh So, assign to whatever contains the debian/elilo.sh script


I think mounting FAT using UTF-8 isn't wise at all. debian/elilo.sh is  
perfect since it specifies the right charset.
If you would change the script to use UTF-8 (explicit or implicit by  
the default), you would make things worse.


I don't want to start a discussion about the UTF-8 default for FAT  
here but you can read, for example, in the Using UTF-8 with Gentoo  
[2] of the Gentoo project:
You should avoid setting Default iocharset for fat to UTF-8, as it is  
not recommended.


The reason is that you will experience 'glyphed' characters in  
filenames when you exchange FAT volumes with Windows when you mount  
FAT using UTF-8 on Linux. Since the user would run into trouble, using  
UTF-8 for FAT isn't wise. Older Linux kernels report a warning message  
when you mount FAT with UTF-8.

So assigning the bug to the elilo package would be wrong.
The kernel-image for normal operation has iso8859-1, why the kernel  
for the installer shouldn't have it either?





The only mistake I have made was:
affects 685186 elilo-installer.
It should have been
affects 685186 elilo.



I think the discussion about severity levels of bugs is academic. Ones  
could have different opinions about that.

Much better would be fixing the bug since it is a real show stopper.

It is just a change of one code line...


Stephan




[1] http://www.debian.org/Bugs/Developer.en.html
[2] http://www.gentoo.org/doc/en/utf-8.xml#doc_chap3


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679545: ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource

2012-10-02 Thread Stephan Schreiber


Thanks a lot for testing this!  I'll fix up this typo and work on
getting something like this merged.


Thank you very much!
If you want me to test anything, don't hesitate to contact me.



What's the output of dmesg | grep :00:1f.1; lspci -vs00:1f.1?


[0.065506] pci :00:1f.1: [8086:24cb] type 0 class 0x000101
[0.065520] pci :00:1f.1: reg 10: [io  0x-0x0007]
[0.065531] pci :00:1f.1: reg 14: [io  0x-0x0003]
[0.065542] pci :00:1f.1: reg 18: [io  0x-0x0007]
[0.065553] pci :00:1f.1: reg 1c: [io  0x-0x0003]
[0.065564] pci :00:1f.1: reg 20: [io  0x1000-0x100f]
[0.065575] pci :00:1f.1: reg 24: [mem 0x-0x03ff unset]
[1.415250] ata_piix :00:1f.1: version 2.13
[1.415276] ata_piix :00:1f.1: can't derive routing for PCI INT A
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller  
(rev 02) (prog-if 8a [Master SecP PriP])

Subsystem: Intel Corporation Device 3404
Flags: bus master, medium devsel, latency 0
I/O ports at 01f0 [size=8]
I/O ports at 03f4 [size=1]
I/O ports at 0170 [size=8]
I/O ports at 0374 [size=1]
I/O ports at 1000 [size=16]
Kernel driver in use: ata_piix




Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679545: ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource

2012-09-29 Thread Stephan Schreiber


Hello Bjorn,
thank you very much for the patch.
I tested it; it works.

(typing mistake: it must read PCI_COMMAND_MEMORY instead of  
PCI_COMMAND_MEM at one location;
some hunks of the patch couldn't be applied automatically on Kernel  
3.2.23 because some comments in the contexts are different)


The dmesg output:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-3-mckinley (Debian 3.2.23-1)  
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) )  
#1 SMP Fri Sep 28 21:57:11 CEST 2012

...
[0.065510] pci :00:1f.1: [8086:24cb] type 0 class 0x000101
[0.065524] pci :00:1f.1: reg 10: [io  0x-0x0007]
[0.065535] pci :00:1f.1: reg 14: [io  0x-0x0003]
[0.065546] pci :00:1f.1: reg 18: [io  0x-0x0007]
[0.065556] pci :00:1f.1: reg 1c: [io  0x-0x0003]
[0.065567] pci :00:1f.1: reg 20: [io  0x1000-0x100f]
[0.065578] pci :00:1f.1: reg 24: [mem 0x-0x03ff unset]
...
[1.391380] libata version 3.00 loaded.
[1.391922] ata_piix :00:1f.1: version 2.13
[1.391938] ata_piix :00:1f.1: can't derive routing for PCI INT A
[1.392493] scsi0 : ata_piix
[1.392886] scsi1 : ata_piix
[1.393018] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1000 irq 34
[1.393066] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1008 irq 33
[1.557756] ata1.00: ATAPI: HL-DT-ST DVDRAM GSA-T40N, JR03, max UDMA/33
[1.573616] ata1.00: configured for UDMA/33
[1.579147] scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM  
GSA-T40N  JR03 PQ: 0 ANSI: 5
[1.590806] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw  
xa/form2 cdda tray

[1.590872] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.591272] sr 0:0:0:0: Attached scsi CD-ROM sr0
[1.593910] sr 0:0:0:0: Attached scsi generic sg0 type 5
...


How is the chance to get this patch or a similar one into linux-next?




On x86, Windows normally doesn't reconfigure PCI devices unless it
finds a problem with the configuration done by the BIOS.  I suspect
it works similarly on ia64.  I would guess that Windows noticed that
the MEM bit was not set, and therefore ignored the MEM BAR contents.


Since I have the four Windows versions 'for Itanium Based Systems' on  
that box as well (XP, Server 2003, 2008, 2008 R2), I can tell you more:
The Device Manager shows a memory range FFBFFC00-FFBF for the  
Intel 82801DB Ultra ATA Storage Controller-24CB - on any of these  
Windows versions.



Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679545: [RFC/PATCH v2] ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource

2012-09-24 Thread Stephan Schreiber

Mpfff, there aren't many replies; seems I didn't satisfy what you want  
to have...


At first I want to mention that I just want to help the Debian project  
and started testing Debian Wheezy my old ia64 box.
Since these are my first messages on the kernel lists, I really don't  
feel me in a position to tell you what's right or wrong for the Kernel  
- I guess you have much more Linux Kernel knowledge than me.




The firmware left the memory BAR at 0x24 cleared (0x), but it
also left the MEM bit in the command register disabled.  So it seems
like a Linux bug that we're trying to use that zero address from the
BAR.  If the firmware left the MEM or IO decode enable bit cleared,
why would we assume it put anything useful in the corresponding BARs?


Your idea would be a fundamental change in the Kernel; I just want to  
fix the ata_piix problem in Debian Wheezy.


I can't tell you whether the developer of the EFI thought this. Maybe  
it is simply a bug.
If you would evaluate the command registers, which the BIOS or EFI has  
initialized, you would work around some wrong BARs. You might run into  
trouble due to wrong command register values instead.

Are you sure that any BIOS or EFI sets the command registers correctly?

Currently the Linux Kernel sets and clears the IORESOURCE_MEM and  
IORESOURCE_IO bits in the command registers as needed.
Windows reconfigures any PCI device. The settings of the BIOS or EFI  
do not matter at all; the user doesn't experience any BIOS bug at all.







This still isn't very generic.  It only looks at BAR 5 and only for
IDE controllers, so it fixes the problem for this device and this
BIOS, but there's no reason the same problem couldn't happen on other
devices and other BARs.

My proposal was basically:

pci_read_config_word(dev, PCI_COMMAND, cmd);
for (i = 0; i  6; i++) {
/* read BAR i here */
r = dev-resource[i];
if (((r-flags  IORESOURCE_MEM)  (cmd  PCI_COMMAND_MEMORY)) ||
((r-flags  IORESOURCE_IO)  (cmd  PCI_COMMAND_IO))) {
/* treat resource as valid */
} else {
/* treat resource as unassigned; try to assign it later */
}
}


Both of my two patches hide the BAR5 when we know that BAR5 is not functional.
The first patch makes sure that the PCI device id matches; the second  
one checks whether it is an ide controller in legacy mode. The  
associated ide/piix or ata/ata_piix doesn't need the BAR5 memory  
resource at all.

The other BARs are functional and needed.

I don't know what regression can occur when you hide *any*  
uninitialized BAR of *any* pci device. Some drivers might be screwed  
up when a needed mem resource is absend - after pci_enable_device() or  
pcim_enable_device() returned success.




Ben Hutchings of the Debian project pointed to some interesting detail  
about ide/piix:

By the way, the reason the old IDE driver worked is that
drivers/ide/setup-pci.c has a fallback for this:

if (pci_enable_device(dev)) {
ret = pci_enable_device_io(dev);

It was added almost exactly 10 years ago without any specific comment.


Debian had both ide/piix and ata/ata_piix in the past. When ata_piix  
didn't initialize, ide/piix took over the device. The user didn't  
experience any problem.
The old ide/piix has been removed with recent Debian versions (due to  
problems with shared interrupts). Thus, the ICH4 problem is on the  
table again.



Since you don't want to take my patches, I need some new ideas. The  
patch shouldn't be a fundamental, experimental change with the risk of  
regression because it is intended for a *stable* Debian release.


Suggestions or comments are appreciated.

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679545: [RFC/PATCH v2] ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource

2012-09-20 Thread Stephan Schreiber

);
pos = pci_find_capability(dev, PCI_CAP_ID_SSVID);
if (pos) {
 			pci_read_config_word(dev, pos + PCI_SSVID_VENDOR_ID,  
dev-subsystem_vendor);
 			pci_read_config_word(dev, pos + PCI_SSVID_DEVICE_ID,  
dev-subsystem_device);

}
break;

case PCI_HEADER_TYPE_CARDBUS:   /* CardBus bridge header */
if (class != PCI_CLASS_BRIDGE_CARDBUS)
goto bad;
pci_read_irq(dev);
pci_read_bases(dev, 1, 0);
 		pci_read_config_word(dev, PCI_CB_SUBSYSTEM_VENDOR_ID,  
dev-subsystem_vendor);

pci_read_config_word(dev, PCI_CB_SUBSYSTEM_ID, 
dev-subsystem_device);
break;

default:/* unknown header */
dev_err(dev-dev, unknown header type %02x, 
ignoring device\n, dev-hdr_type);
return -EIO;

bad:
dev_err(dev-dev, ignoring class %02x (doesn't match header 
type %02x)\n, class, dev-hdr_type);
dev-class = PCI_CLASS_NOT_DEFINED;
}

/* We found a fine healthy device, go go go... */
return 0;
 }

 static void pci_release_capabilities(struct pci_dev *dev)
 {
pci_vpd_release(dev);
pci_iov_release(dev);
 }

 /**
  * pci_release_dev - free a pci device structure when all users of  
it are finished.

  * @dev: device that's been disconnected
  *
  * Will be called only by the device core when all users of this pci  
device are

  * done.
  */
 static void pci_release_dev(struct device *dev)
 {
struct pci_dev *pci_dev;

pci_dev = to_pci_dev(dev);
pci_release_capabilities(pci_dev);



Signed-off-by: Stephan Schreiber i...@fs-driver.org


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679545: [RFC/PATCH] ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource

2012-09-16 Thread Stephan Schreiber

: version 2.13
[1.392807] ata_piix :00:1f.1: can't derive routing for PCI INT A
[1.399383] scsi0 : ata_piix
[1.402505] scsi1 : ata_piix
[1.402609] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1000 irq 34
[1.402658] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1008 irq 33
[1.565703] ata1.00: ATAPI: HL-DT-ST DVDRAM GSA-T40N, JR03, max UDMA/33
[1.581571] ata1.00: configured for UDMA/33
[1.587075] scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM  
GSA-T40N  JR03 PQ: 0 ANSI: 5
[1.598796] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw  
xa/form2 cdda tray

[1.598863] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.599263] sr 0:0:0:0: Attached scsi CD-ROM sr0
[1.601972] sr 0:0:0:0: Attached scsi generic sg0 type 5
...


(Note: The patch of this posting differs slightly from the one which I  
have posted on Debian bug#679545 - just cosmetic improvements.)


Kind regards,
Stephan Schreiber



--- linux-3.2.23/arch/ia64/pci/fixup.c.orig	2012-09-16  
11:23:30.0 +0200

+++ linux-3.2.23/arch/ia64/pci/fixup.c  2012-09-16 11:52:13.0 +0200
@@ -67,3 +67,40 @@ static void __devinit pci_fixup_video(st
}
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
+
+
+/*
+ * Fixup the EFI bug of Intel's SR870 platform
+ *
+ * The EFI of Intel's SR870BH2 and SR870BN4 including their OEM  
equivalents by

+ * Fujitsu and Dell doesn't initialize the memory resource of the ICH4 IDE
+ * hostadapter. The memory resource has the default after reset: 0x0-0x3FF.
+ * The ata_piix driver uses pcim_enable_device() which attempts to  
enable this

+ * along with the I/O BARs and pcim_enable_device() fails because the memory
+ * region 0x0-0x3FF cannot be allocated.
+ * The memory resource is the 6th resource of the ICH4 IDE hostadapter;
+ * Intel's datasheet Intel 82801DB I/O Controller Hub 4 (ICH4) (Document
+ * Number: 290744-001) states in section 10.1.15 EXBAR - Expansion Base
+ * Address Register (IDE-D31:F1) on page 389:
+ * This is a memory mapped BAR ... that is Intel reserved for future
+ * functionality. BIOS needs to program the base address for a 1-KB memory
+ * space.
+ * Since nothing uses the EXBAR, we hide it so that only the I/O BARs will be
+ * enabled.
+ */
+
+static void __devinit pci_fixup_sr870_ich4(struct pci_dev *dev)
+{
+   struct resource *r;
+
+   r = dev-resource[5];
+   if ((r-flags  IORESOURCE_MEM)
+r-start == 0  r-end != 0) {
+   dev_info(dev-dev,
+   SR870 EFI bug workaround; hide EXBAR memory 
resource.\n);
+   r-flags = 0;
+   r-end = 0;
+   }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_11,
+   pci_fixup_sr870_ich4);

Signed-off-by: Stephan Schreiber i...@fs-driver.org


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679545: IA64 (Itanium) Wheezy, doesn't detect DVD drive, new patch proposal

2012-09-15 Thread Stephan Schreiber

 for UDMA/33
[1.575094] scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM  
GSA-T40N  JR03 PQ: 0 ANSI: 5
[1.586476] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw  
xa/form2 cdda tray

[1.586542] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.586943] sr 0:0:0:0: Attached scsi CD-ROM sr0
[1.589562] sr 0:0:0:0: Attached scsi generic sg0 type 5


The ICH4-L IDE works with the ata_piix module now. The DVD drive works  
without a flaw.

What do think about the patch?

Kind regards
Stephan Schreiber



ia64-ich4l-exbar.patch
Description: ia64-ich4l-exbar.patch
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-3-mckinley (Debian 3.2.23-1) 
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP 
Sat Sep 15 14:01:23 CEST 2012
[0.00] EFI v1.10 by INTEL: SALsystab=0x7fe4c8c0 ACPI=0x7ff99000 ACPI 
2.0=0x7ff98000 MPS=0x7ff97000 SMBIOS=0xf
[0.00] booting generic kernel on platform dig
[0.00] ACPI: RSDP 7ff98000 00024 (v02 INTEL )
[0.00] ACPI: XSDT 7ff98090 00034 (v01 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ACPI: FACP 7ff98138 000F4 (v03 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ACPI: DSDT 7ff9a000 02937 (v01  Intel SR870BH2  
MSFT 010D)
[0.00] ACPI: FACS 7ff982e0 00040
[0.00] ACPI: APIC 7ff98230 000AE (v01 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ia64_native_iosapic_pcat_compat_init: Disabling PC-AT compatible 
8259 interrupts
[0.00] ACPI: Local APIC address c000fee0
[0.00] 2 CPUs available, 2 CPUs total
[0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[0.00] Initial ramdisk at: 0xe001fdd2a000 (18856823 bytes)
[0.00] SAL 3.1: Intel Corp   SR870BH2   
  version 3.0
[0.00] SAL Platform features: BusLock IRQ_Redirection
[0.00] SAL: AP wakeup using external interrupt vector 0xf0
[0.00] MCA related initialization done
[0.00] Virtual mem_map starts at 0xa0007e40
[0.00] Zone PFN ranges:
[0.00]   DMA  0x0400 - 0x0004
[0.00]   Normal   0x0004 - 0x0008
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[4] active PFN ranges
[0.00] 0: 0x0400 - 0x0001fe80
[0.00] 0: 0x0001ffa6 - 0x0001ffd1
[0.00] 0: 0x0006 - 0x0007ff84
[0.00] 0: 0x0007ffa0 - 0x0007ffed
[0.00] On node 0 totalpages: 260732
[0.00] free_area_init_node: node 0, pgdat e190, 
node_mem_map a0007e40e000
[0.00]   DMA zone: 893 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 128814 pages, LIFO batch:7
[0.00]   Normal zone: 896 pages used for memmap
[0.00]   Normal zone: 130129 pages, LIFO batch:7
[0.00] pcpu-alloc: s13824 r8192 d240128 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 258943
[0.00] Policy zone: Normal
[0.00] Kernel command line: BOOT_IMAGE=scsi0:/EFI/debian/vmlinuz 
root=/dev/sdb5  ro
[0.00] PID hash table entries: 4096 (order: 1, 32768 bytes)
[0.00] Placing 64MB software IO TLB between e4cb4000 - 
e8cb4000
[0.00] software IO TLB at phys 0x4cb4000 - 0x8cb4000
[0.00] Memory: 4050880k/4140208k available (7801k code, 120832k 
reserved, 4455k data, 1184k init)
[0.00] Hierarchical RCU implementation.
[0.00]  CONFIG_RCU_FANOUT set to non-default value of 32
[0.00] NR_IRQS:1024
[0.00] ia64_native_iosapic_pcat_compat_init: Disabling PC-AT compatible 
8259 interrupts
[0.00] ACPI: Local APIC address c000fee0
[0.00] PLATFORM int CPEI (0x3): GSI 22 (level, low) - CPU 0 (0xc018) 
vector 30
[0.00] register_intr: changing vector 39 from IO-SAPIC-edge to 
IO-SAPIC-level
[0.00] CPU 0: base freq=199.463MHz, ITC ratio=15/2, ITC freq=1495.974MHz
[0.00] Console: colour VGA+ 80x25
[0.00] console [tty0] enabled
[0.004000] Calibrating delay loop... 2232.32 BogoMIPS (lpj=4464640)
[0.032046] pid_max: default: 32768 minimum: 301
[0.032268] Security Framework initialized
[0.032319] AppArmor: AppArmor disabled by boot time parameter
[0.032556] Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes)
[0.037674] Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes)
[0.040335] Mount-cache hash table entries: 1024
[0.041018] Initializing cgroup subsys cpuacct
[0.041095] Initializing cgroup subsys memory
[0.041409] Initializing cgroup subsys devices
[0.041452] Initializing cgroup subsys freezer
[0.041493] Initializing cgroup subsys net_cls

Bug#679545: IA64 (Itanium) Wheezy, doesn't detect DVD drive and NIC, patch proposal

2012-09-09 Thread Stephan Schreiber


Hello,

I just installed the unmodified Wheezy kernel  
(linux-image-3.2.0-3-mckinley_3.2.23.1_ia64.deb).


The dmesg output is attached.

Kind regards
Stephan Schreiber

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-3-mckinley (Debian 3.2.23-1) 
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP 
Mon Jul 23 09:01:02 UTC 2012
[0.00] EFI v1.10 by INTEL: SALsystab=0x7fe4c8c0 ACPI=0x7ff99000 ACPI 
2.0=0x7ff98000 MPS=0x7ff97000 SMBIOS=0xf
[0.00] booting generic kernel on platform dig
[0.00] ACPI: RSDP 7ff98000 00024 (v02 INTEL )
[0.00] ACPI: XSDT 7ff98090 00034 (v01 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ACPI: FACP 7ff98138 000F4 (v03 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ACPI: DSDT 7ff9a000 02937 (v01  Intel SR870BH2  
MSFT 010D)
[0.00] ACPI: FACS 7ff982e0 00040
[0.00] ACPI: APIC 7ff98230 000AE (v01 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ia64_native_iosapic_pcat_compat_init: Disabling PC-AT compatible 
8259 interrupts
[0.00] ACPI: Local APIC address c000fee0
[0.00] 2 CPUs available, 2 CPUs total
[0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[0.00] Initial ramdisk at: 0xe001fdd2a000 (18856835 bytes)
[0.00] SAL 3.1: Intel Corp   SR870BH2   
  version 3.0
[0.00] SAL Platform features: BusLock IRQ_Redirection
[0.00] SAL: AP wakeup using external interrupt vector 0xf0
[0.00] MCA related initialization done
[0.00] Virtual mem_map starts at 0xa0007e40
[0.00] Zone PFN ranges:
[0.00]   DMA  0x0400 - 0x0004
[0.00]   Normal   0x0004 - 0x0008
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[4] active PFN ranges
[0.00] 0: 0x0400 - 0x0001fe80
[0.00] 0: 0x0001ffa6 - 0x0001ffd1
[0.00] 0: 0x0006 - 0x0007ff84
[0.00] 0: 0x0007ffa0 - 0x0007ffed
[0.00] On node 0 totalpages: 260732
[0.00] free_area_init_node: node 0, pgdat e190, 
node_mem_map a0007e40e000
[0.00]   DMA zone: 893 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 128814 pages, LIFO batch:7
[0.00]   Normal zone: 896 pages used for memmap
[0.00]   Normal zone: 130129 pages, LIFO batch:7
[0.00] pcpu-alloc: s13824 r8192 d240128 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 258943
[0.00] Policy zone: Normal
[0.00] Kernel command line: BOOT_IMAGE=scsi0:/EFI/debian/vmlinuz 
root=/dev/sdb5  ro
[0.00] PID hash table entries: 4096 (order: 1, 32768 bytes)
[0.00] Placing 64MB software IO TLB between e4cb4000 - 
e8cb4000
[0.00] software IO TLB at phys 0x4cb4000 - 0x8cb4000
[0.00] Memory: 4050880k/4140208k available (7801k code, 120832k 
reserved, 4455k data, 1184k init)
[0.00] Hierarchical RCU implementation.
[0.00]  CONFIG_RCU_FANOUT set to non-default value of 32
[0.00] NR_IRQS:1024
[0.00] ia64_native_iosapic_pcat_compat_init: Disabling PC-AT compatible 
8259 interrupts
[0.00] ACPI: Local APIC address c000fee0
[0.00] PLATFORM int CPEI (0x3): GSI 22 (level, low) - CPU 0 (0xc018) 
vector 30
[0.00] register_intr: changing vector 39 from IO-SAPIC-edge to 
IO-SAPIC-level
[0.00] CPU 0: base freq=199.463MHz, ITC ratio=15/2, ITC freq=1495.974MHz
[0.00] Console: colour VGA+ 80x25
[0.00] console [tty0] enabled
[0.004000] Calibrating delay loop... 2232.32 BogoMIPS (lpj=4464640)
[0.032047] pid_max: default: 32768 minimum: 301
[0.032268] Security Framework initialized
[0.032319] AppArmor: AppArmor disabled by boot time parameter
[0.032557] Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes)
[0.037677] Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes)
[0.040334] Mount-cache hash table entries: 1024
[0.041016] Initializing cgroup subsys cpuacct
[0.041093] Initializing cgroup subsys memory
[0.041408] Initializing cgroup subsys devices
[0.041451] Initializing cgroup subsys freezer
[0.041492] Initializing cgroup subsys net_cls
[0.041536] Initializing cgroup subsys blkio
[0.041637] ACPI: Core revision 20110623
[0.044248] Boot processor id 0x0/0xc018
[0.00] Fixed BSP b0 value from CPU 1
[0.00] CPU 1: synchronized ITC with CPU 0 (last diff 5 cycles, maxerr 
534 cycles)
[0.00] CPU 1: base freq=199.463MHz, ITC ratio=15/2, ITC freq=1495.974MHz
[0.050921] Brought up 2 CPUs
[0.050963] Total of 2

Bug#679545: IA64 (Itanium) Wheezy, doesn't detect DVD drive and NIC, patch proposal

2012-09-09 Thread Stephan Schreiber

Here is the dmesg output from a kernel that differs from the previous  
one in the enabled piix driver.


Kind regards
Stephan Schreiber

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-3-mckinley (Debian 3.2.23-1) 
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP 
Sat Aug 18 20:50:43 UTC 2012
[0.00] EFI v1.10 by INTEL: SALsystab=0x7fe4c8c0 ACPI=0x7ff99000 ACPI 
2.0=0x7ff98000 MPS=0x7ff97000 SMBIOS=0xf
[0.00] booting generic kernel on platform dig
[0.00] ACPI: RSDP 7ff98000 00024 (v02 INTEL )
[0.00] ACPI: XSDT 7ff98090 00034 (v01 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ACPI: FACP 7ff98138 000F4 (v03 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ACPI: DSDT 7ff9a000 02937 (v01  Intel SR870BH2  
MSFT 010D)
[0.00] ACPI: FACS 7ff982e0 00040
[0.00] ACPI: APIC 7ff98230 000AE (v01 INTEL  SR870BH2 01072002 
MSFT 00010013)
[0.00] ia64_native_iosapic_pcat_compat_init: Disabling PC-AT compatible 
8259 interrupts
[0.00] ACPI: Local APIC address c000fee0
[0.00] 2 CPUs available, 2 CPUs total
[0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[0.00] Initial ramdisk at: 0xe001fdd2a000 (18855198 bytes)
[0.00] SAL 3.1: Intel Corp   SR870BH2   
  version 3.0
[0.00] SAL Platform features: BusLock IRQ_Redirection
[0.00] SAL: AP wakeup using external interrupt vector 0xf0
[0.00] MCA related initialization done
[0.00] Virtual mem_map starts at 0xa0007e40
[0.00] Zone PFN ranges:
[0.00]   DMA  0x0400 - 0x0004
[0.00]   Normal   0x0004 - 0x0008
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[4] active PFN ranges
[0.00] 0: 0x0400 - 0x0001fe80
[0.00] 0: 0x0001ffa6 - 0x0001ffd1
[0.00] 0: 0x0006 - 0x0007ff84
[0.00] 0: 0x0007ffa0 - 0x0007ffed
[0.00] On node 0 totalpages: 260732
[0.00] free_area_init_node: node 0, pgdat e190, 
node_mem_map a0007e40e000
[0.00]   DMA zone: 893 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 128814 pages, LIFO batch:7
[0.00]   Normal zone: 896 pages used for memmap
[0.00]   Normal zone: 130129 pages, LIFO batch:7
[0.00] pcpu-alloc: s13824 r8192 d240128 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 258943
[0.00] Policy zone: Normal
[0.00] Kernel command line: BOOT_IMAGE=scsi0:/EFI/debian/vmlinuz 
root=/dev/sdb5  ro
[0.00] PID hash table entries: 4096 (order: 1, 32768 bytes)
[0.00] Placing 64MB software IO TLB between e4cb4000 - 
e8cb4000
[0.00] software IO TLB at phys 0x4cb4000 - 0x8cb4000
[0.00] Memory: 4050880k/4140208k available (7801k code, 120832k 
reserved, 4455k data, 1200k init)
[0.00] Hierarchical RCU implementation.
[0.00]  CONFIG_RCU_FANOUT set to non-default value of 32
[0.00] NR_IRQS:1024
[0.00] ia64_native_iosapic_pcat_compat_init: Disabling PC-AT compatible 
8259 interrupts
[0.00] ACPI: Local APIC address c000fee0
[0.00] PLATFORM int CPEI (0x3): GSI 22 (level, low) - CPU 0 (0xc018) 
vector 30
[0.00] register_intr: changing vector 39 from IO-SAPIC-edge to 
IO-SAPIC-level
[0.00] CPU 0: base freq=199.463MHz, ITC ratio=15/2, ITC freq=1495.975MHz
[0.00] Console: colour VGA+ 80x25
[0.00] console [tty0] enabled
[0.004000] Calibrating delay loop... 2232.32 BogoMIPS (lpj=4464640)
[0.032047] pid_max: default: 32768 minimum: 301
[0.032268] Security Framework initialized
[0.032319] AppArmor: AppArmor disabled by boot time parameter
[0.032557] Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes)
[0.037677] Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes)
[0.040338] Mount-cache hash table entries: 1024
[0.041019] Initializing cgroup subsys cpuacct
[0.041096] Initializing cgroup subsys memory
[0.041409] Initializing cgroup subsys devices
[0.041452] Initializing cgroup subsys freezer
[0.041494] Initializing cgroup subsys net_cls
[0.041537] Initializing cgroup subsys blkio
[0.041638] ACPI: Core revision 20110623
[0.044251] Boot processor id 0x0/0xc018
[0.00] Fixed BSP b0 value from CPU 1
[0.00] CPU 1: synchronized ITC with CPU 0 (last diff 5 cycles, maxerr 
534 cycles)
[0.00] CPU 1: base freq=199.463MHz, ITC ratio=15/2, ITC freq=1495.975MHz
[0.050918] Brought up 2 CPUs
[0.050960] Total of 2 processors activated (4464.64 BogoMIPS

Bug#686152: xorg server 1.12.3: xf86UnloadSubModule() hangs, patch proposal

2012-09-07 Thread Stephan Schreiber

I took a look at the most recent code in xorg's git repository  
(http://cgit.freedesktop.org/xorg/xserver/tree/).
All the functions which has been considered in this bug report do not  
differ from the ones of xorg-server 1.12.3:

hw/xfree86/common/xf86Helper.c: xf86UnloadSubModule()
hw/xfree86/loader/loadmod.c: UnloadModuleOrDriver(),  
UnloadSubModule(), RemoveChild(ModuleDescPtr()
with one exception that isn't relevant for our issue -  
UnloadModuleOrDriver() of 1.13 uses another function for log messages  
than 1.12.3.



I assume that the issue is also present on xorg-server 1.13.


Kind regards
Stephan Schreiber


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#659186: Segmentation fault in libmozjs185.so.1.0 at startup, patch proposal

2012-09-07 Thread Stephan Schreiber


Hello,

the mentioned patch for Iceweasel
http://hg.mozilla.org/integration/mozilla-inbound/rev/9c15d0fb3e25
of the Mozilla bug#589735  
(https://bugzilla.mozilla.org/show_bug.cgi?id=589735) which modifed  
the pages_map() function in memory/jemalloc/jemalloc.c doesn't match  
with the renewed code in libmozjs185-1.0.


But I think a similar patch for libmozjs185-1.0 is feasible.
The MapPages() function in js/src/jsgcchunk.cpp, line 319 (applied on  
Linux/Unix) can be patched in a similar way.


A patch proposal for libmozjs185-1.0 is attached.

Since my Itanium box has a really outdated ATI graphics which lacks  
the needed hardware acceleration, I'm not able to run Gnome shell in  
order to test the result of the patch.


Please could you do that?

The built package can be downloaded here:
http://www.fs-driver.org/debian-ia64/libmozjs185-1.0_1.8.5-1.0.0+dfsg-3.1_ia64.deb



Kind regards
Stephan Schreiber



mozjs-ia64.patch
Description: mozjs-ia64.patch

Bug#686152: xorg server 1.12.3: xf86UnloadSubModule() hangs, patch proposal

2012-09-06 Thread Stephan Schreiber

) LoadModule: ati
[32.074] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[32.080] (II) Module ati: vendor=X.Org Foundation
[32.099]compiled for 1.12.1.902, module version = 6.14.4
[32.099]Module class: X.Org Video Driver
[32.099]ABI class: X.Org Video Driver, version 12.0
[32.099] (II) LoadModule: mach64
[32.100] (II) Loading /usr/lib/xorg/modules/drivers/mach64_drv.so
[32.122] (II) Module mach64: vendor=X.Org Foundation
[32.122]compiled for 1.12.3, module version = 6.9.1
[32.122]Module class: X.Org Video Driver
[32.122]ABI class: X.Org Video Driver, version 12.0
[32.128] (II) LoadModule: fbdev
[32.128] (WW) Warning, couldn't open module fbdev
[32.128] (II) UnloadModule: fbdev
[32.128] (II) Unloading fbdev
[32.128] (EE) Failed to load module fbdev (module does not exist, 0)
[32.128] (II) MACH64: Driver for ATI Mach64 chipsets
[32.128] (--) using VT number 7

[32.132] (II) MACH64(0): Creating default Display subsection in  
Screen section

Default Screen Section for depth/fbbpp 24/32
[32.132] (==) MACH64(0): Depth 24, (--) framebuffer bpp 32
[32.132] (==) MACH64(0): Using XAA acceleration architecture
[32.132] (II) MACH64: Mach64 in slot 1:1:0 detected.
[32.132] (II) Loading sub module int10
[32.132] (II) LoadModule: int10
[32.132] (II) Loading /usr/lib/xorg/modules/libint10.so
[32.173] (II) Module int10: vendor=X.Org Foundation
[32.173]compiled for 1.12.3, module version = 1.0.0
[32.173]ABI class: X.Org Video Driver, version 12.0
[32.177] (II) Loading sub module ddc
[32.177] (II) LoadModule: ddc
[32.177] (II) Module ddc already built-in
[32.177] (II) Loading sub module vbe
[32.177] (II) LoadModule: vbe
[32.177] (II) Loading /usr/lib/xorg/modules/libvbe.so
[32.185] (II) Module vbe: vendor=X.Org Foundation
[32.185]compiled for 1.12.3, module version = 1.1.0
[32.185]ABI class: X.Org Video Driver, version 12.0
[32.185] (II) MACH64(0): VESA BIOS not detected
[32.185] (II) UnloadSubModule: vbe
[32.185] (II) Unloading vbe
[32.185] (II) UnloadSubModule: int10
[32.185] (II) Unloading int10
[32.185] (II) MACH64(0): BIOS Data:  BIOSSize=0x8000, ROMTable=0x0114.
[32.185] (II) MACH64(0): BIOS Data:  ClockTable=0x097C,  
FrequencyTable=0x.

[32.185] (II) MACH64(0): BIOS Data:  LCDTable=0x.
[32.185] (II) MACH64(0): BIOS Data:  VideoTable=0x,  
HardwareTable=0x015E.
[32.185] (II) MACH64(0): BIOS Data:  I2CType=0x0F, Tuner=0x00,  
Decoder=0x00, Audio=0x0F.
[32.185] (--) MACH64(0): ATI 3D Rage XL or XC graphics controller  
detected.
[32.185] (--) MACH64(0): Chip type 4752 GR, version 7, foundry  
TSMC, class 0, revision 0x00.
[32.185] (--) MACH64(0): PCI bus interface detected;  block I/O  
base is 0xCC00.

[32.185] (--) MACH64(0): ATI Mach64 adapter detected.
[32.185] (!!) MACH64(0): For information on using the multimedia  
capabilities

of this adapter, please see http://gatos.sf.net.
[32.185] (--) MACH64(0): Internal RAMDAC (subtype 1) detected.
[32.185] (==) MACH64(0): RGB weight 888
[32.185] (==) MACH64(0): Default visual is TrueColor




It includes successful submodule unloads now:
[32.185] (II) UnloadSubModule: vbe
[32.185] (II) Unloading vbe
[32.185] (II) UnloadSubModule: int10
[32.185] (II) Unloading int10



Kind regards
Stephan Schreiber





unloadsubmodule.patch
Description: unloadsubmodule.patch

Bug#686150: xorg server 1.12.3: xf86UnloadSubModule() hangs

: vendor=X.Org Foundation
[   157.130]compiled for 1.12.3, module version = 1.0.0
[   157.130]ABI class: X.Org Server Extension, version 6.0
[   157.130] (==) AIGLX enabled
[   157.130] (II) Loading extension GLX
[   157.130] (II) LoadModule: record
[   157.130] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[   157.130] (II) Module record: vendor=X.Org Foundation
[   157.131]compiled for 1.12.3, module version = 1.13.0
[   157.131]Module class: X.Org Server Extension
[   157.131]ABI class: X.Org Server Extension, version 6.0
[   157.131] (II) Loading extension RECORD
[   157.131] (II) LoadModule: dri
[   157.131] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[   157.143] (II) Module dri: vendor=X.Org Foundation
[   157.143]compiled for 1.12.3, module version = 1.0.0
[   157.143]ABI class: X.Org Server Extension, version 6.0
[   157.143] (II) Loading extension XFree86-DRI
[   157.143] (II) LoadModule: dri2
[   157.143] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[   157.143] (II) Module dri2: vendor=X.Org Foundation
[   157.143]compiled for 1.12.3, module version = 1.2.0
[   157.143]ABI class: X.Org Server Extension, version 6.0
[   157.143] (II) Loading extension DRI2
[   157.143] (==) Matched ati as autoconfigured driver 0
[   157.143] (==) Matched fbdev as autoconfigured driver 1
[   157.143] (==) Assigned the driver to the xf86ConfigLayout
[   157.143] (II) LoadModule: ati
[   157.144] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[   157.151] (II) Module ati: vendor=X.Org Foundation
[   157.151]compiled for 1.12.1.902, module version = 6.14.4
[   157.151]Module class: X.Org Video Driver
[   157.151]ABI class: X.Org Video Driver, version 12.0
[   157.151] (II) LoadModule: mach64
[   157.151] (II) Loading /usr/lib/xorg/modules/drivers/mach64_drv.so
[   157.151] (II) Module mach64: vendor=X.Org Foundation
[   157.151]compiled for 1.12.3, module version = 6.9.1
[   157.151]Module class: X.Org Video Driver
[   157.151]ABI class: X.Org Video Driver, version 12.0
[   157.151] (II) LoadModule: fbdev
[   157.152] (WW) Warning, couldn't open module fbdev
[   157.152] (II) UnloadModule: fbdev
[   157.152] (II) Unloading fbdev
[   157.152] (EE) Failed to load module fbdev (module does not exist, 0)
[   157.152] (II) MACH64: Driver for ATI Mach64 chipsets
[   157.152] (--) using VT number 7

[   157.155] (II) MACH64(0): Creating default Display subsection in  
Screen section

Default Screen Section for depth/fbbpp 24/32
[   157.155] (==) MACH64(0): Depth 24, (--) framebuffer bpp 32
[   157.155] (==) MACH64(0): Using XAA acceleration architecture
[   157.155] (II) MACH64: Mach64 in slot 1:1:0 detected.
[   157.155] (II) Loading sub module int10
[   157.155] (II) LoadModule: int10
[   157.155] (II) Loading /usr/lib/xorg/modules/libint10.so
[   157.155] (II) Module int10: vendor=X.Org Foundation
[   157.155]compiled for 1.12.3, module version = 1.0.0
[   157.155]ABI class: X.Org Video Driver, version 12.0
[   157.156] (WW) MACH64(0): Unable to retrieve all of segment 0x0C.
[   157.156] (II) Loading sub module ddc
[   157.156] (II) LoadModule: ddc
[   157.156] (II) Module ddc already built-in
[   157.156] (II) Loading sub module vbe
[   157.156] (II) LoadModule: vbe
[   157.156] (II) Loading /usr/lib/xorg/modules/libvbe.so
[   157.156] (II) Module vbe: vendor=X.Org Foundation
[   157.156]compiled for 1.12.3, module version = 1.1.0
[   157.156]ABI class: X.Org Video Driver, version 12.0
[   157.156] (II) MACH64(0): VESA BIOS not detected
[   157.156] (II) UnloadSubModule: vbe
[   157.156] (II) Unloading vbe
[   157.157] (II) UnloadSubModule: int10
[   157.157] (II) Unloading int10
[   157.157] (II) UnloadSubModule: cë
[   157.157] (II) Unloading cë


I could figure out that the problem is in the xf86UnloadSubModule()  
function in hw/xfree86/common/xf86Helper.c of xorg-server-core 1.12.3:


void
xf86UnloadSubModule(pointer mod)
{
UnloadSubModule(mod);
}

Earlier the function read in hw/xfree86/common/xf86Helper.c of  
xorg-server-core 1.11.4:


void
xf86UnloadSubModule(pointer mod)
{
/*
 * This is disabled for now.  The loader isn't smart enough yet to undo
 * relocations.
 */
#if 0
UnloadSubModule(mod);
#endif
}

Conclusion: UnloadSubModule() was and is still buggy.
I commented out UnloadSubModule(mod) tentative in 1.12.3, the X server  
started successful after that.


So the solution would be either comment out UnloadSubModule() or fix it...

Kind regards
Stephan Schreiber


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#686151: xorg server 1.12.3: int10 driver always reports 'Unable to retrieve all of segment 0x0C0000.'


Package: xserver-xorg-core
Source: xserver-xorg-core
Severity: normal
Tags: wheezy



Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 4G
Graphics: build-in ATI Rage XL
01:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI Rage XL [1002:4752] (rev 27)
Subsystem: Intel Corporation Device [8086:3404]



Hello,
I noticed that the build-in int10 driver always reports
Unable to retrieve all of segment 0x0C.
even though the entire BIOS data is retrieved with success.


The associated code is in hw/xfree86/int10/generic.c, in the function  
xf86ExtendedInitInt10():


if (pci_device_read_rom(pInt-dev, vbiosMem)  V_BIOS_SIZE) {
xf86DrvMsg(screen, X_WARNING,
   Unable to retrieve all of segment 0x0C.\n);
}

The function pci_device_read_rom() is from libpciaccess; its return  
value is not a size but an error status code: 0 means success.

If pci_device_read_rom() returns 0 for success, the warning is generated.

Earlier, in xorg-server-core 1.11.4 the first line of the code snippet  
used the read_legacy_video_BIOS() function instead:


if (read_legacy_video_BIOS(pInt-dev, vbiosMem)  V_BIOS_SIZE) {
xf86DrvMsg(screen, X_WARNING,
   Unable to retrieve all of segment 0x0C.\n);
}

The read_legacy_video_BIOS() function is in hw/xfree86/int10/generic.c  
of xorg-server-core-1.11.4:


#ifndef _PC
static int
read_legacy_video_BIOS(struct pci_device *dev, unsigned char *Buf)
{
const ADDRESS Base = 0xC;
const int Len = 0x1 * 2;
const int pagemask = getpagesize() - 1;
const ADDRESS offset = Base  ~pagemask;
const unsigned long size = ((Base + Len + pagemask)  ~pagemask) - offset;
unsigned char *ptr, *src;
int len;


/* Try to use the civilized PCI interface first.
 */
if (pci_device_read_rom(dev, Buf) == 0) {
return dev-rom_size;
}

ptr = xf86MapDomainMemory(-1, VIDMEM_READONLY, dev, offset, size);

if (!ptr)
return -1;

/* Using memcpy() here can hang the system */
src = ptr + (Base - offset);
for (len = 0; len  (Len / 2); len++) {
Buf[len] = src[len];
}

if ((Buf[0] == 0x55)  (Buf[1] == 0xAA)  (Buf[2]  0x80)) {
for ( /* empty */ ; len  Len; len++) {
Buf[len] = src[len];
}
}

xf86UnMapVidMem(-1, ptr, size);

return Len;
}
#endif /* _PC */


read_legacy_video_BIOS() has been removed, xf86MapDomainMemory() and  
xf86UnMapVidMem() are gone.

The call of pci_device_read_rom() is in xf86ExtendedInitInt10() now.

The proposed patch corrects the evaluation of the return value of  
pci_device_read_rom() and of the supplied BIOS size.



Kind regards
Stephan Schreiber




int10-warning.patch
Description: int10-warning.patch

Bug#686152: xorg server 1.12.3: xf86UnloadSubModule() hangs

 Foundation
[   157.130]compiled for 1.12.3, module version = 1.0.0
[   157.130]ABI class: X.Org Server Extension, version 6.0
[   157.130] (==) AIGLX enabled
[   157.130] (II) Loading extension GLX
[   157.130] (II) LoadModule: record
[   157.130] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[   157.130] (II) Module record: vendor=X.Org Foundation
[   157.131]compiled for 1.12.3, module version = 1.13.0
[   157.131]Module class: X.Org Server Extension
[   157.131]ABI class: X.Org Server Extension, version 6.0
[   157.131] (II) Loading extension RECORD
[   157.131] (II) LoadModule: dri
[   157.131] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[   157.143] (II) Module dri: vendor=X.Org Foundation
[   157.143]compiled for 1.12.3, module version = 1.0.0
[   157.143]ABI class: X.Org Server Extension, version 6.0
[   157.143] (II) Loading extension XFree86-DRI
[   157.143] (II) LoadModule: dri2
[   157.143] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[   157.143] (II) Module dri2: vendor=X.Org Foundation
[   157.143]compiled for 1.12.3, module version = 1.2.0
[   157.143]ABI class: X.Org Server Extension, version 6.0
[   157.143] (II) Loading extension DRI2
[   157.143] (==) Matched ati as autoconfigured driver 0
[   157.143] (==) Matched fbdev as autoconfigured driver 1
[   157.143] (==) Assigned the driver to the xf86ConfigLayout
[   157.143] (II) LoadModule: ati
[   157.144] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[   157.151] (II) Module ati: vendor=X.Org Foundation
[   157.151]compiled for 1.12.1.902, module version = 6.14.4
[   157.151]Module class: X.Org Video Driver
[   157.151]ABI class: X.Org Video Driver, version 12.0
[   157.151] (II) LoadModule: mach64
[   157.151] (II) Loading /usr/lib/xorg/modules/drivers/mach64_drv.so
[   157.151] (II) Module mach64: vendor=X.Org Foundation
[   157.151]compiled for 1.12.3, module version = 6.9.1
[   157.151]Module class: X.Org Video Driver
[   157.151]ABI class: X.Org Video Driver, version 12.0
[   157.151] (II) LoadModule: fbdev
[   157.152] (WW) Warning, couldn't open module fbdev
[   157.152] (II) UnloadModule: fbdev
[   157.152] (II) Unloading fbdev
[   157.152] (EE) Failed to load module fbdev (module does not exist, 0)
[   157.152] (II) MACH64: Driver for ATI Mach64 chipsets
[   157.152] (--) using VT number 7

[   157.155] (II) MACH64(0): Creating default Display subsection in  
Screen section

Default Screen Section for depth/fbbpp 24/32
[   157.155] (==) MACH64(0): Depth 24, (--) framebuffer bpp 32
[   157.155] (==) MACH64(0): Using XAA acceleration architecture
[   157.155] (II) MACH64: Mach64 in slot 1:1:0 detected.
[   157.155] (II) Loading sub module int10
[   157.155] (II) LoadModule: int10
[   157.155] (II) Loading /usr/lib/xorg/modules/libint10.so
[   157.155] (II) Module int10: vendor=X.Org Foundation
[   157.155]compiled for 1.12.3, module version = 1.0.0
[   157.155]ABI class: X.Org Video Driver, version 12.0
[   157.156] (WW) MACH64(0): Unable to retrieve all of segment 0x0C.
[   157.156] (II) Loading sub module ddc
[   157.156] (II) LoadModule: ddc
[   157.156] (II) Module ddc already built-in
[   157.156] (II) Loading sub module vbe
[   157.156] (II) LoadModule: vbe
[   157.156] (II) Loading /usr/lib/xorg/modules/libvbe.so
[   157.156] (II) Module vbe: vendor=X.Org Foundation
[   157.156]compiled for 1.12.3, module version = 1.1.0
[   157.156]ABI class: X.Org Video Driver, version 12.0
[   157.156] (II) MACH64(0): VESA BIOS not detected
[   157.156] (II) UnloadSubModule: vbe
[   157.156] (II) Unloading vbe
[   157.157] (II) UnloadSubModule: int10
[   157.157] (II) Unloading int10
[   157.157] (II) UnloadSubModule: cë
[   157.157] (II) Unloading cë


I could figure out that the problem is in the xf86UnloadSubModule()  
function in hw/xfree86/common/xf86Helper.c of xorg-server-core 1.12.3:


void
xf86UnloadSubModule(pointer mod)
{
UnloadSubModule(mod);
}

Earlier the function read in hw/xfree86/common/xf86Helper.c of  
xorg-server-core 1.11.4:


void
xf86UnloadSubModule(pointer mod)
{
/*
 * This is disabled for now.  The loader isn't smart enough yet to undo
 * relocations.
 */
#if 0
UnloadSubModule(mod);
#endif
}

Conclusion: UnloadSubModule() was and is still buggy.
I commented out UnloadSubModule(mod) tentative in 1.12.3, the X server  
started successful after that.


So the solution would be either comment out UnloadSubModule() or fix it...

Kind regards
Stephan Schreiber


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#686153: xorg server 1.12.3: int10 driver always reports 'Unable to retrieve all of segment 0x0C0000.'


Package: xorg-server
Source: xorg-server
Severity: normal
Tags: wheezy



Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 4G
Graphics: build-in ATI Rage XL
01:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI Rage XL [1002:4752] (rev 27)
Subsystem: Intel Corporation Device [8086:3404]



Hello,
I noticed that the build-in int10 driver always reports
Unable to retrieve all of segment 0x0C.
even though the entire BIOS data is retrieved with success.


The associated code is in hw/xfree86/int10/generic.c, in the function  
xf86ExtendedInitInt10():


if (pci_device_read_rom(pInt-dev, vbiosMem)  V_BIOS_SIZE) {
xf86DrvMsg(screen, X_WARNING,
   Unable to retrieve all of segment 0x0C.\n);
}

The function pci_device_read_rom() is from libpciaccess; its return  
value is not a size but an error status code: 0 means success.

If pci_device_read_rom() returns 0 for success, the warning is generated.

Earlier, in xorg-server-core 1.11.4 the first line of the code snippet  
used the read_legacy_video_BIOS() function instead:


if (read_legacy_video_BIOS(pInt-dev, vbiosMem)  V_BIOS_SIZE) {
xf86DrvMsg(screen, X_WARNING,
   Unable to retrieve all of segment 0x0C.\n);
}

The read_legacy_video_BIOS() function is in hw/xfree86/int10/generic.c  
of xorg-server-core-1.11.4:


#ifndef _PC
static int
read_legacy_video_BIOS(struct pci_device *dev, unsigned char *Buf)
{
const ADDRESS Base = 0xC;
const int Len = 0x1 * 2;
const int pagemask = getpagesize() - 1;
const ADDRESS offset = Base  ~pagemask;
const unsigned long size = ((Base + Len + pagemask)  ~pagemask) - offset;
unsigned char *ptr, *src;
int len;


/* Try to use the civilized PCI interface first.
 */
if (pci_device_read_rom(dev, Buf) == 0) {
return dev-rom_size;
}

ptr = xf86MapDomainMemory(-1, VIDMEM_READONLY, dev, offset, size);

if (!ptr)
return -1;

/* Using memcpy() here can hang the system */
src = ptr + (Base - offset);
for (len = 0; len  (Len / 2); len++) {
Buf[len] = src[len];
}

if ((Buf[0] == 0x55)  (Buf[1] == 0xAA)  (Buf[2]  0x80)) {
for ( /* empty */ ; len  Len; len++) {
Buf[len] = src[len];
}
}

xf86UnMapVidMem(-1, ptr, size);

return Len;
}
#endif /* _PC */


read_legacy_video_BIOS() has been removed, xf86MapDomainMemory() and  
xf86UnMapVidMem() are gone.

The call of pci_device_read_rom() is in xf86ExtendedInitInt10() now.

The proposed patch corrects the evaluation of the return value of  
pci_device_read_rom() and of the supplied BIOS size.



Kind regards
Stephan Schreiber




int10-warning.patch
Description: int10-warning.patch

Bug#685750: IA64 (Itanium) Wheezy, mach64, decommissioned xorg drivers, patch proposal