Help Desk Support | 21 May 23:15 2015

Dear Web-Mail User

Dear E-mail User
Due to spam report against our domain, we are now providing more security services, all active users are
requested to verify their Web-Mail account by providing the below account information to continue
enjoying better services:

E-mail ID:
Confirm Password:

Unverified account will be considered inactive and deactivated within 48-hours, we apologize for the
inconveniences caused.

Best Service
Admin Service

William D. Jones | 7 May 12:12 2015

Build failure using GENERIC_TINY kernel config

Hello all,

As some users/devs know, I run NetBSD-current on a 486 for fun. I figured it 
was about time to upgrade the kernel after about 5 months. The current 
kernel config I use is a slightly-modified GENERIC_TINY in the usual 
sys/arc/i386/conf directory. I suspect my changes to the kernel conf- which 
are meant to add in driver dev- do not have any effect on the problems I am 
having. As of this morning, I can not compile the kernel due to missing 
references to a recently-added PCI device that is a dependency of 

#      link  PB_KERNEL/netbsd
 -Map --cref -T 
/home/william/Projects/NetBSD-CVS/src/sys/arch/i386/conf/kern.ldscript -Ttext 
c0100000 -e start -X -o netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
intr.o: In function `intr_allocate_slot_cpu':
intr.c:(.text+0x2d1): undefined reference to `msipic_is_msi_pic'
intr.o: In function `intr_disestablish':
intr.c:(.text+0xa4d): undefined reference to `msipic_is_msi_pic'
intr.o: In function `intr_establish':
intr.c:(.text+0xb94): undefined reference to `msipic_get_devid'
intr.c:(.text+0xbd3): undefined reference to `pci_msi_string'
intr.c:(.text+0xc4d): undefined reference to `msipic_is_msi_pic'

*** Failed target:  netbsd
*** Failed command: echo '# ' " link PB_KERNEL/netbsd"; echo 
 -Map --cref -T 
/home/william/Projects/NetBSD-CVS/src/sys/arch/i386/conf/kern.ldscript -Ttext 
(Continue reading)

Greg A. Woods | 27 Apr 09:56 2015

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

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:
at netbsd:nfs_lookup+0xfda
Apr 11 00:48:54 charm /netbsd:
at netbsd:VOP_LOOKUP+0x50
Apr 11 00:48:54 charm /netbsd:
(Continue reading) | 8 Apr 14:51 2015

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

Illegal instruction trap in


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, and things started to work

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

Firefox24 segfault on startup (vs Gslice/glib)


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...

$ 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)

$ 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 it's due to Gslice with glib
versions => 2.35 (current version here = glib2-2.40.0).

(no PR sent).

Mathieu Lubrano.
(Continue reading)

Ms. Zou | 8 Jan 19:10 2015



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. 

Ms. Zou 
Sales manager. 

William D. Jones | 7 Jan 20:39 2015

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)


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

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 :