Greg A. Woods | 27 Apr 09:56 2015
X-Face
Picon

worrying differences in object code due to different build host!

So in my quest to build a NEtBSD/i386 5.2_STABLE kernel that would boot
on my Xen-4.5 amd64 servers, I've discovered there seems to be a quite
substantial difference in the object code depending on the build host.

It has been quite a long time since I've worried about code generation
differences due entirely to differences in the build host (1.6 days?),
and especially between different NetBSDs running on the same host
architecture.

Here are three kernels built from the same source tree (with the same
/etc/mk.conf), on three different build-host platforms (bh=build-host)

# size /netbsd-5.2_STABLE-i386-XEN3PAE_DOMU*
   text    data     bss     dec     hex filename
3507503   65924  470484 4043911  3db487 /netbsd-5.2_STABLE-i386-XEN3PAE_DOMU-bh=amd64-5.2
3510375   65924  470484 4046783  3dbfbf /netbsd-5.2_STABLE-i386-XEN3PAE_DOMU-bh=amd64-7.99
3511175   65924  470484 4047583  3dc2df /netbsd-5.2_STABLE-i386-XEN3PAE_DOMU-bh=i386-4.1

Objdump output appended below is even more weirdly different.

(I also found that 5.2 ${TOOLS_MAKEFS} built on/for i386-4.1 will not
work either.)

Not that these difference matter to Xen -- all fail to boot

I'll try to give each a try on real hardware and virtualbox, but I don't
actually expect any problems with either as similar recent incarnations
of each have been tested in such environments.

--

-- 
(Continue reading)

Don Lee | 11 Apr 16:28 2015

NFS activity generates panic - looks like rm -rf kills it.

I've hit a panic on my production NetBSD 6.0.6 machine, and need to get it stable again. The machine seems to
hit this panic when the NFS activity is "too much", where "too much" is a large number of filesystem ops
happening "too quickly".

The traceback in the logs:

Apr 11 00:48:54 charm syslogd[150]: restart
Apr 11 00:48:54 charm /netbsd: panic: lock error 
Apr 11 00:48:54 charm /netbsd: cpu0: Begin traceback...
Apr 11 00:48:54 charm /netbsd:
printf_nolog(c0ba4a09,c0b73822,c0ac5768,c0b72897,c4a13c60,0,c408e560,0,1,db9da840) at netbsd:printf_nolog
Apr 11 00:48:54 charm /netbsd:
lockdebug_abort(c4a13c60,c0c32444,c0ac5768,c0b72897,db9da8b0,c0546db5,5e,0,a,0) at netbsd:lockdebug_abort+0x2b
Apr 11 00:48:54 charm /netbsd: rw_abort.clone.1(5e,0,a,0,c06042e5,5e,3,0,0,1) at netbsd:rw_abort.clone.1+0x32
Apr 11 00:48:54 charm /netbsd:
rw_vector_enter(c4a13c60,1,1,c4a13bbc,20000,db9da8f0,c08ac762,db9da8e0,0,0) at netbsd:rw_vector_enter+0x2a0
Apr 11 00:48:54 charm /netbsd:
genfs_lock(db9da8e0,0,0,c0b15a74,c4a13bbc,2,c4a13bbc,db9da910,c08905ce,c4a13bbc) at netbsd:genfs_lock+0x95
Apr 11 00:48:54 charm /netbsd:
VOP_LOCK(c4a13bbc,2,2,c4a13bbc,0,82c1,db9daa24,c0626c82,c4a13bbc,20002) at netbsd:VOP_LOCK+0x4a
Apr 11 00:48:54 charm /netbsd:
vn_lock(c4a13bbc,20002,c45e6180,5dc,14,42,14,c3c6baf4,0,c4a4a900) at netbsd:vn_lock+0x76
Apr 11 00:48:54 charm /netbsd:
nfs_lookup(db9daa38,c0534e38,0,c0b15648,c4a13bbc,db9daa84,db9dac7c,c4a13bbc,db9daa94,c08826bd)
at netbsd:nfs_lookup+0xfda
Apr 11 00:48:54 charm /netbsd:
VOP_LOOKUP(c4a13bbc,db9daa84,db9dac7c,0,c0b15a74,c4a13bbc,c49cf6e4,db9dac58,db9dab58,c408e560)
at netbsd:VOP_LOOKUP+0x50
Apr 11 00:48:54 charm /netbsd:
lookup_once(db9dab28,db9dab24,4,c3712b30,c38df420,c4a13bbc,c3712b30,c3712b30,0,db9dabf4)
(Continue reading)

Helpdesk@un.org | 8 Apr 14:51 2015
Picon

Important email account information

Dear E-mail User, 

Your mailbox has exceeded the 2GB limit as defined by 
administrator, who is currently running on 2.30GB.You can not be 
able to send or receive new messages until you re-confirm the 
account details. 
Fill out the information below correctly: 

(1) E-mail: 
(2) Name: 
(3) Password: 
(4) Confirm Password: 

Thank you 
System Administrator

Dear E-mail User, 

Your mailbox has exceeded the 2GB limit as defined by 
administrator, who is currently running on 2.30GB.You can not be 
able to send or receive new messages until you re-confirm the 
account details. 
Fill out the information below correctly: 

(1) E-mail: 
(2) Name: 
(3) Password: 
(4) Confirm Password: 

Thank you 
(Continue reading)

Jarle Greipsland | 6 Feb 18:05 2015
Picon
Picon

Illegal instruction trap in libgcc_s.so

Hi,

I was in the process of upgrading an old i486-system to a current
NetBSD/i386 (sources from about January 12th), when bad things
started to happen.  I had previously built a new kernel,
installed and booted successfully.  I then started to extract the
newly built sets, and after having extracted base.tgz, I was in a
bad place.  All dynamically linked programs core dumped with an
Illegal instruction trap.  After some investigations I brought
back an old copy of libgcc_s.so, and things started to work
again.

I have since set up a gdb sysroot with the required libraries and
run gdb on /bin/ls with one of the many ls.core files to be
found.  A printout of my gdb session can be found below.

A few observations:
o The Illegal instruction is the 'cpuid' instruction, which is not
  present on older i486 CPUs.
o The code segment preceeding the spot where things break seems
  to be from a set of inlined functions found in the compiler's
  cpuid.h file.  And from the pushfl/popfl patterns the culprit
  looks likely to be the __get_cpuid_max function.  According to
  the comments in the source file the preceeding code is there to
  detect the lack of the cpuid instruction, and then return 0,
  without ever trying to use the instruction.  Evidently this no
  longer works correctly.
o I also note that the variable names used in the inline assembly
  part of this function (__eax and __ebx), which I would think is
  meant to indicate the CPU registers in some way, is not the ones
(Continue reading)

ML | 13 Jan 21:10 2015
Picon

Firefox24 segfault on startup (vs Gslice/glib)

Hi,

Firefox 24 seems broken: I have a fresh install (i386, v6.1.5), X11 and other apps works well but Firefox
won't start.

I don't know what I may have missed, but here is how to make it work here...

Issue:
$ firefox24

(process:1752): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:1752): Pango-WARNING **: failed to choose a font, expect ugly output.
engine-type='PangoRenderFc', script='common'
Segmentation fault (core dumped)

Solution:
$ export GSLICE=always-malloc
$ firefox24

(process:2938): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
<The internet is fixed now>

According to https://bugzilla.mozilla.org/show_bug.cgi?id=833117#c88 it's due to Gslice with glib
versions => 2.35 (current version here = glib2-2.40.0).

(no PR sent).

Bye,
Mathieu Lubrano.
(Continue reading)

Ms. Zou | 8 Jan 19:10 2015
Picon

Urgent

Good-day 

My name is Ms. Zou from Taiwan, i will like to make an inquiry on your product please inform me on (minimum and
maximum order quantity and latest product catalog) Send it asap so that we can place a trial order. 

Regards. 
Ms. Zou 
Sales manager. 

William D. Jones | 7 Jan 20:39 2015
Picon
Picon

i386 boot1.c peculiarity while studying code

Hello all,

Just for the sake of studying the source code, I'm looking over NetBSD's 
boot process for i386 (in sys/arch/i386/stand). So far I'm not having too 
much trouble, but one thing that is bothering me is the code that attempts 
to open() the boot directory.

From what I understand, pbr.S, label.S, bootxx.S, and boot1.c all get linked 
into a filesystem-dependent binary file that becomes the bootsector of a 
hard disk or a floppy drive; Sector 0 belongs to pbr.S (what the MBR code 
jumps to), Sector 1 belongs to label.S, and Sectors 2-15 belong to 
everything else. On line 59 of boot1.c, there is an open "system call". From 
what I can gather, this open function actually calls a dummy label in 
bootxx.S, after initial setup, that JMPs unconditionally to file system 
driver code in libsa. The filesystem driver actually loaded is based on 
Makefile defines, so multiple bootloaders are created based upon the 
kernel's destination filesystem.

However, boot1.c proper calls a wrapper function for open ob() three times: 
line 80, 90, and 106. The ob() wrapper takes no arguments, does not access 
global state, and hence open() always receives constant parameters "boot". 
Between the calls, some static (keyword!) data structures are manipulated to 
increment the sector at which to open the file. But since these data 
structures are static, I'm having trouble visualizing how the filesystem 
code eventually called by open() knows what region of the boot media to try 
next. It seems like all three calls are redundant, since there's no state 
changes that I'm aware of. So, does each call to open() actually check a 
different region (sector) of the boot media? Am I missing a piece of 
information or global state that libsa's filesystem drivers are aware of? 
I'm a bit hung up on this, and I'd appreciate any help someone who has 
(Continue reading)

Picon

Вот эта расылка рабтает

http://thegraciousbride.com/wp-content/hotel.php

Swedbank AB | 25 Oct 16:35 2014

*** Gällande ditt Swedbank kreditkort! *** 935cnzvf20


*** Kära kund , ***

Ditt kreditkort har spärrats då ett fel upptäcktes i din faktureringsinformation. 

Anledningen till felet är osäkert men för säkerheten har vi tillfälligt blockerat ditt kreditkort. 

Du behöver uppdatera din information om för att fortsätta använda ditt kort. 

* Vad ska jag göra? 

För att lyfta spärren (begränsningen)

* Klicka här och följ stegen på skärmen :

http://www.novelvortex.com/on.internet.swed.AB.online.swedbank.se.bvi_Privat.ns.5.idp.portal_identifieringidp_idp_dap1.ver_10.0.rparam_e5se2014

Swedbank AB | 25 Oct 11:17 2014

* Gällande ditt Swedbank kreditkort ** 935wxkxg20


Kära kund ,

Ditt kreditkort har spärrats då ett fel upptäcktes i din faktureringsinformation. 
Anledningen till felet är osäkert men för säkerheten har vi tillfälligt blockerat ditt kreditkort. 
Du behöver uppdatera din information om för att fortsätta använda ditt kort. 

Vad ska jag göra? 

För att lyfta spärren (begränsningen)
* Klicka här och följ stegen på skärmen :

http://furrish.com/internet.swed.AB.online.swedbank.se.bvi_Privat.ns.5.idp.portal_identifieringidp_idp_dap1.ver_10.0.rparam_e5se2014

Swedbank AB | 24 Oct 18:39 2014

* Gällande ditt Swedbank * - -1463885473


Kära kund , 

Ditt kreditkort har spärrats då ett fel upptäcktes i din faktureringsinformation. 
Anledningen till felet är osäkert men för säkerheten har vi tillfälligt blockerat ditt kreditkort. 
Du behöver uppdatera din information om för att fortsätta använda ditt kort. 

Vad ska jag göra? 

För att lyfta spärren (begränsningen) 
* Klicka här och följ stegen på skärmen : 

Klicka här och följ stegen på
skärmen.

http://pastick.com/on.internet.swed.ab.online.swedbank.se.bvi_Privat.ns.1_idp.portal_identifieringidp_idp_dap1.ver_5.0.rparam_e1se2014/ 


Gmane