BUG REPORT

BUG REPORT

[Luca T.]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

Hello,
reiserfsck failed to rebuild the tree of my root partition (thank god it was 
not the home partition).
I send you the log of the operation.

Thank you,
   Luca



root@ttyp0[knoppix]# reiserfsck --rebuild-tree --logfile log.txt /dev/hdg1
<--------reiserfsck 3.6.6, 2003-------->

  *************************************************************
  ** Do not run rebuild-tree unless something is broken  and **
  ** MAKE A BACKUP before using it.  If you have bad sectors **
  ** on a drive  it is usually a bad idea  to continue using **
  ** it.  Then you probably should get a working hard drive, **
  ** copy the file system from the bad drive to the good one **
  ** -- dd_rescue is  a good tool for  that -- and only then **
  ** run this program.                                       **
  ** If you are using the latest reiserfsprogs and  it fails **
  ** please  email bug reports to reiserfs-list@namesys.com, **
  ** providing  as  much  information  as  possible --  your **
  ** hardware,  kernel,  patches,  settings,  all reiserfsck **
  ** messages  (including version),  the reiserfsck logfile, **
  ** check  the  syslog file  for  any  related information. **
  ** If you would like advice on using this program, support **
  ** is available  for $25 at  www.namesys.com/support.html. **
  *************************************************************

Will rebuild the filesystem (/dev/hdg1) tree
Will put log info to 'log.txt'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
0 transactions replayed
###########
reiserfsck --rebuild-tree started at Tue Jan 13 19:36:10 2004
###########

Pass 0:
Loading on-disk bitmap .. ok, 2615500 blocks marked used
Skipping 8290 blocks (super block, journal, bitmaps) 2607210 blocks will be 
read
0%....20%....40%....60%....80%....100%                       left 0, 14404 /
sec
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 2607210
                Leaves among those 10901
                Objectids found 1109

Pass 1 (will try to insert 10901 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....Not enough allocable blocks, checking 
bitmap...there are 1 allocable blocks, btw

out of disk space
Abortito
root@ttyp0[knoppix]#



[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 99 bytes --]

####### Pass 0 #######
245918 directory entries were hashed with "r5" hash.
####### Pass 1 #######

Re: BUG REPORT

[David D. Huff Jr.]

Luca T. wrote:
> Hello,
> reiserfsck failed to rebuild the tree of my root partition (thank god it was 
> not the home partition).
> I send you the log of the operation.
> 
> Thank you,
>    Luca
> 
> 
> 
> root@ttyp0[knoppix]# reiserfsck --rebuild-tree --logfile log.txt /dev/hdg1
> <--------reiserfsck 3.6.6, 2003-------->
> 
>   *************************************************************
>   ** Do not run rebuild-tree unless something is broken  and **
>   ** MAKE A BACKUP before using it.  If you have bad sectors **
>   ** on a drive  it is usually a bad idea  to continue using **
>   ** it.  Then you probably should get a working hard drive, **
>   ** copy the file system from the bad drive to the good one **
>   ** -- dd_rescue is  a good tool for  that -- and only then **
>   ** run this program.                                       **
>   ** If you are using the latest reiserfsprogs and  it fails **
>   ** please  email bug reports to reiserfs-list@namesys.com, **
>   ** providing  as  much  information  as  possible --  your **
>   ** hardware,  kernel,  patches,  settings,  all reiserfsck **
>   ** messages  (including version),  the reiserfsck logfile, **
>   ** check  the  syslog file  for  any  related information. **
>   ** If you would like advice on using this program, support **
>   ** is available  for $25 at  www.namesys.com/support.html. **
>   *************************************************************
> 
> Will rebuild the filesystem (/dev/hdg1) tree
> Will put log info to 'log.txt'
> 
> Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
> Replaying journal..
> 0 transactions replayed
> ###########
> reiserfsck --rebuild-tree started at Tue Jan 13 19:36:10 2004
> ###########
> 
> Pass 0:
> Loading on-disk bitmap .. ok, 2615500 blocks marked used
> Skipping 8290 blocks (super block, journal, bitmaps) 2607210 blocks will be 
> read
> 0%....20%....40%....60%....80%....100%                       left 0, 14404 /
> sec
>         "r5" hash is selected
> Flushing..finished
>         Read blocks (but not data blocks) 2607210
>                 Leaves among those 10901
>                 Objectids found 1109
> 
> Pass 1 (will try to insert 10901 leaves):
> Looking for allocable blocks .. finished
> 0%....20%....40%....60%....80%....Not enough allocable blocks, checking 
> bitmap...there are 1 allocable blocks, btw
> 
> out of disk space
> Abortito
> root@ttyp0[knoppix]#
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ####### Pass 0 #######
> 245918 directory entries were hashed with "r5" hash.
> ####### Pass 1 #######

I've had that condition since Friday, I'll be watching the responses you 
get. I've attempted all the suggestions, tonight I'm going to dd to 
another harddrive and try to --rebuild-tree there. Good Luck!

Re: BUG REPORT

[Vitaly Fertman]

Hello Luca,

would you tell me details about what happened before rebuilding?
why did you decided that fs is corrupted?

would you also run 
	debugreiserfs -d /dev/hdg1 | bzip2 -c > hdg1.bz2
and provide it somehow for downloading. 

we have not got out of disk at fscking for a long time but the 
2nd time recently, I would like to find the source of the problem.

would you also update the reiserfsprogs, 3.6.6 is out-of-date version.

-- 
Thanks,
Vitaly Fertman

On Tuesday 13 January 2004 22:09, Luca T. wrote:
> Hello,
> reiserfsck failed to rebuild the tree of my root partition (thank god it
> was not the home partition).
> I send you the log of the operation.
>
> Thank you,
>    Luca
>
>
>
> root@ttyp0[knoppix]# reiserfsck --rebuild-tree --logfile log.txt /dev/hdg1
> <--------reiserfsck 3.6.6, 2003-------->
>
>   *************************************************************
>   ** Do not run rebuild-tree unless something is broken  and **
>   ** MAKE A BACKUP before using it.  If you have bad sectors **
>   ** on a drive  it is usually a bad idea  to continue using **
>   ** it.  Then you probably should get a working hard drive, **
>   ** copy the file system from the bad drive to the good one **
>   ** -- dd_rescue is  a good tool for  that -- and only then **
>   ** run this program.                                       **
>   ** If you are using the latest reiserfsprogs and  it fails **
>   ** please  email bug reports to reiserfs-list@namesys.com, **
>   ** providing  as  much  information  as  possible --  your **
>   ** hardware,  kernel,  patches,  settings,  all reiserfsck **
>   ** messages  (including version),  the reiserfsck logfile, **
>   ** check  the  syslog file  for  any  related information. **
>   ** If you would like advice on using this program, support **
>   ** is available  for $25 at  www.namesys.com/support.html. **
>   *************************************************************
>
> Will rebuild the filesystem (/dev/hdg1) tree
> Will put log info to 'log.txt'
>
> Do you want to run this program?[N/Yes] (note need to type Yes if you
> do):Yes Replaying journal..
> 0 transactions replayed
> ###########
> reiserfsck --rebuild-tree started at Tue Jan 13 19:36:10 2004
> ###########
>
> Pass 0:
> Loading on-disk bitmap .. ok, 2615500 blocks marked used
> Skipping 8290 blocks (super block, journal, bitmaps) 2607210 blocks will be
> read
> 0%....20%....40%....60%....80%....100%                       left 0, 14404
> / sec
>         "r5" hash is selected
> Flushing..finished
>         Read blocks (but not data blocks) 2607210
>                 Leaves among those 10901
>                 Objectids found 1109
>
> Pass 1 (will try to insert 10901 leaves):
> Looking for allocable blocks .. finished
> 0%....20%....40%....60%....80%....Not enough allocable blocks, checking
> bitmap...there are 1 allocable blocks, btw
>
> out of disk space
> Abortito
> root@ttyp0[knoppix]#

Bug report

[Dexter Pontañeles]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
I was trying to merge another branch to my branch but then got
conflicts. After resolving the conflicts, I wanted to continue the
merge operation but a hook was failing. I wanted to bypass this hook
by adding --no-verify flag: git merge --continue --no-verify

What did you expect to happen? (Expected behavior)
I expected the merge operation to continue, bypassing the hook

What happened instead? (Actual behavior)
git command failed with error `fatal: --continue expects no arguments`

What's different between what you expected and what actually happened?
The operation failed instead of proceeding with the git merge operation

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.42.0
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05
PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64
compiler info: clang: 14.0.3 (clang-1403.0.22.14.1)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]

Bug Report

[Tiago d'Almeida]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Hello!

I'm Tiago and sorry for any mistake because it is my first bug report to git.

So after git updated, I begin to get some errors and unexpected git
status output.

I made a test git repo to test this, and here are the results:

```
mkdir git_bug && cd git_bug
git init -q && git maintenance register && echo "Done!"
touch <files>
mkdir <folders>
touch <files in folders>
git status --short

## No commits yet on main
?? LICENSE
?? README.md
?? folder/
?? folder_1/

git add <files>
git status

## No commits yet on main
?? LICENSE
?? README.md
?? folder/
?? folder_1/

git commit -s -m "First commit"

On branch main

Initial commit

Untracked files:
LICENSE
README.md
folder/
folder_1/

nothing added to commit but untracked files present

```

Attached to this email follow the `git bugreport` and global `config`
files, and the git_bug repo.

I've checked my global config file and it seems all ok, but if there
is some error or contradicition, please tell me.

Thanks in advance!

[-- Attachment #2: git-bugreport-2023-06-27-1643.txt --]
[-- Type: text/plain, Size: 971 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

A normal git routine.
- git add <files>
- git commit -s -m "Commit"

What did you expect to happen? (Expected behavior)

No errors and the files being added and commited.

What happened instead? (Actual behavior)

No files added. Error when tried to commit.

What's different between what you expected and what actually happened?

The error.

Anything else you want to add:

This just happened after updating git to version 2.41 


[System Info]
git version 2.41.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.3.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 15 02:15:40 UTC 2023 x86_64
compiler info: gnuc: 13.1
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /usr/bin/fish


[Enabled Hooks]

[-- Attachment #3: global_config --]
[-- Type: application/octet-stream, Size: 7090 bytes --]

# TIAGO d'ALMEIDA GIT CONFIG


# These directives includes the user.name and user.email according to the repo location.
[include]
  path = "./config_d/personal"

[includeIf "gitdir:~/Projects/work/"]
  path = "./config_d/work"

[includeIf "gitdir:~/Work/"]
  path = "./config_d/work"

[alias]
  a   = add
  aa  = add --all .
  ai  = add -i
  aac = ! git add --all . && git commit -m
  br  = branch
  cl  = clone
  cm  = commit -s -m
  cml = commit -s
  cp  = cherry-pick
  d   = diff
  f   = fetch
  fa  = fetch --all
  i   = ! git init -q && git maintenance register && echo "Done!"
  l   = log --graph --oneline -n 10
  ls  = log --graph --oneline --all
  lch = log --pretty="format:(%h) %N %an" --show-notes=*
  m   = maintenance run
  ms  = maintenance register
  mu  = maintenance unregister
  nt  = notes
  nta = notes append
  nch = notes append --ref=changelog
  p   = push
  pa  = push --all
  rb  = rebase -i
  r   = reset
  r1  = reset HEAD~
  r2  = reset HEAD~~
  rh  = reset --hard
  rh1 = reset HEAD~ --hard
  rh2 = reset HEAD~~ --hard
  rt  = restore
  s   = status --short
  sl  = status --long
  st  = stash              # equivalent to `stash push`
  stp = stash pop
  stl = stash list
  sta = stash apply
  sts = stash show
  sw  = switch             # switch and restore is the new checkout
  w   = ! watch -n 5 -p -c git -c color.ui=always status

  amend   = commit -s --amend --no-edit
  fixup   = commit -s --fixup

  since   = log --graph --oneline --since="1 week ago"

  track   = add -N
  unstage = restore --staged
  forget  = rm -r --cached

  del     = delete
  delete  = ! git maintenance unregister && rm -rf .git && echo "Done!"
  watch   = ! watch -n 5 -p -c git -c color.ui=always status

  show    = show --show-signature

#	brd = branch -d
#	brD = branch -D
# br_desc = branch --edit-description
#	merged = branch --merged
#	dev = !git checkout dev && git pull origin dev
#	staging = !git checkout staging && git pull origin staging
#	master = !git checkout master && git pull origin 
#	po = push origin
#	pu = !git push origin `git branch --show-current`
#	pod = push origin dev
#	pos = push origin staging
#	pom = push origin main
#	poh = push origin HEAD
#	pogm = !git push origin gh-pages && git checkout master && git pull origin master && git rebase gh-pages && git push origin master && git checkout gh-pages
#	pomg = !git push origin master && git checkout gh-pages && git pull origin gh-pages && git rebase master && git push origin gh-pages && git checkout master
#	plo = pull origin
#	plod = pull origin dev
#	plos = pull origin staging
#	plom = pull origin master
#	ploh = pull origin HEAD
#	f = "!git ls-files | grep -i"
# gr = grep -Ii

[advice]
  addIgnoredFile = false
  statusHints = false

[branch]
  autoSetupMerge = always

[core]
	askPass = ""
  compression = 6
  editor = nano +1
  eol = lf
  filemode = true
  fsmonitor = true
  fsmonitorHookVersion = 2
  fsyncMethod = batch
#  hooksPath = "./hooks" --> can't be this path, correct this in the future; see man git-config
#  notes = refs/notes/commits
  pager = less --tabs=2
#  quotePath = off
  safecrlf = true
  sparseCheckout = true
  sparseCheckoutCone = true
  splitIndex = true
  symlinks = true
  whitespace = space-before-tab, tab-in-indent, trailing-space, tabwidth=2

[add]
#  ignoreErrors = true

[apply]
  ignoreWhitespace = false

[checkout]
  defaultRemote = origin
  workers = 0
  thresholdForParallelism = 100
  
[color]
  ui = auto

[color "advice"]
  hint = dim white

[color "status"]
  header       = italic white
  added        = green
  updated      = cyan
  changed      = brightyellow
  untracked    = dim white
  branch       = bold magenta
  nobranch     = red
  localBranch  = bold magenta
  remoteBranch = brightgreen
  unmerged     = cyan

[column]
  ui = auto, column, dense

[commit]
  gpgSign = true
#  template = "./commit"

[credential]
#  helper = "cache --timeout 18000 --socket ~/.config/git/socket"
  helper = "cache --timeout 18000"

[diff]
  context = 5
  mnemonicPrefix = true
  relative = true
  renames = copies
  algoritm = patience
  wsErrorHighlight = all
  colorMoved = true

[feature]
  experimental = true
  manyFiles = true

[fetch]
  prune = true
  pruneTags = true
  output = compact
  parallel = 3
  writeCommitGraph = true

[filter "lfs"]
  clean = git-lfs clean -- %f
  smudge = git-lfs smudge -- %f
  process = git-lfs filter-process
  required = true

[gc]
  bigPackThreshold    = 1g
  logExpiry           = 1.week
  cruftPacks          = true
  pruneExpire         = 1.week
  worktreePruneExpire = 1.month

[gpg]
  program = gpg2
  minTrustLevel = fully

[help]
  autoCorrect = prompt

[http]
#  cookieFile = ~/.config/git/cookie
  saveCookies = true
  version = HTTP/2
  sslVersion = tlsv1.3
  sslVerify = true

[i18n]
  commitEncoding = utf-8
  logOutputEncoding = utf-8

[index]
  sparse = true
  threads = true

[init]
  defaultBranch = main
#  templateDir = ~/.config/git/template/

[interactive]
  singleKey = true

[lfs "https://github.com/"]
  locksverify = true

[lfs "https://gitlab.com/"]
  locksverify = true

[log]
  decorate = auto
  graphColors = brightwhite, red, green, blue, magenta, yellow, cyan

[lsrefs]
  unborn = advertise

[maintenance]
  auto = false
  strategy = incremental
# commit-graph        - hourly
# prefetch            - hourly
# gc                  - off
# loose-objects       - daily
# incremental-repack  - daily
# pack-refs           - weekly

[maintenance.gc]
  enabled = true
  schedule= weekly

[merge]
  conflictStyle = merge
  ff = only
  verifySignatures = true
  branchdesc = true
  log = true
  renormalize = true
  stat = true
  autoStash = true

#[notes]
#  # https://dev.to/leehambley/effortlessly-maintain-a-high-quality-change-log-with-git-notes-4bm5
##  mergeStrategy = cat_sort_uniq
##  rewriteMode = cat_sort_uniq
##  rewriteRef = refs/notes/commits
#
#[notes "rewrite"]
#  amend = true
#  rebase = true

[pack]
  useBitmaps = true
  useSparse = true
  writeBitmapHashCache =true
  writeReverseIndex = true

# pass command-line tool 
[pass]
  signcommits = true

[protocol]
  version = 2

[pull]
  ff      = only
  rebase  = false
  twohead = ort

[push]
  autoSetupRemote = true
  default = current
  followTags = true
  gpgSign = if-asked
  negotiate = true

[rebase]
  backend = merge
  autoSquash = true
  autoStash = true
  missingCommitsCheck = warn
  abbreviateCommands = true

[remote]
  pushDefault = origin

#[remote "origin"]
#  tagOpt = "--tags"
##  fetch = +refs/heads/*:refs/remotes/origin/*
##  fetch = +refs/notes/*:refs/notes/*
##  push = +refs/heads/*
##  push = +refs/notes/*:refs/notes/*
#
[repack]
  writeBitmaps = true

[rerere]
  autoUpdate = true
  enabled = true

[safe]
  bareRepository = explicit

[splitIndex]
  maxPercentChange = 20

[ssh]
  variant = ssh

[status]
  branch    = true
  showStash = true

[transfer]
  credentialsInUrl = die
  fsckObjects = true

[tag]
  forceSignAnnotated = true
  gpgSign = true

[user]
  useConfigOnly = true
  signingkey = ***********

[versionsort]
  suffix = "-pre"
  suffix = "-rc"
  suffix = ""

[-- Attachment #4: git_bug.tar.gz --]
[-- Type: application/gzip, Size: 11601 bytes --]

Bug report

[Jensen Bean]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
download git
What did you expect to happen? (Expected behavior)
CTRL button to work
What happened instead? (Actual behavior)
CTRL button stops working
What's different between what you expected and what actually happened?
the CTRL button doesn't work when I have git installed
Anything else you want to add:
Deleting git and all its files has been the only thing that works so far
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
Confusing experience, wasn't sure what to actually do

[System Info]
git version:
git version 2.38.1.windows.1
cpu: x86_64
built from commit: b85c8f604d375d4d773a36842964e8a7ec056aae
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 22621
compiler info: gnuc: 12.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


[Enabled Hooks]
not run from a
git repository - no hooks to show
git-bugreport-2022-12-25-0152.txt[+] [unix] (01:52 25/12/2022)

Re: Bug report

[Eric Sunshine]

On Tue, Dec 27, 2022 at 10:09 PM Jensen Bean <jensen.bean@gmail.com> wrote:
> What did you expect to happen? (Expected behavior)
> CTRL button to work
> What happened instead? (Actual behavior)
> CTRL button stops working
> What's different between what you expected and what actually happened?
> the CTRL button doesn't work when I have git installed
>
> [System Info]
> git version:
> git version 2.38.1.windows.1

This sounds like a problem specific to Git for Windows, which is a
separate project. You may want to open a bug report with that
project's issue tracker[1].

[1]: https://github.com/git-for-windows/git/issues

bug report

[Eyal Post]

What did you do before the bug happened? (Steps to reproduce your issue)
1. I have a script which creates a git worktree and checks out a few
files from the master branch
2. When this script runs "stand alone" - everything works fine
3. When this script runs from a "pre-commit" hook it fails with an
error: "fatal: Unable to create '/tmp/wt-1/.git/index.lock': Not a
directory"

The content of the script is (simplified example):
git worktree add /tmp/wt-1 master --no-checkout --detach
cd /tmp/wt-1
git checkout master .


What did you expect to happen? (Expected behavior)
I would expect the script to run just fine as part of the pre-commit hook

What happened instead? (Actual behavior)
An error about .git not being a directory is shown

What's different between what you expected and what actually happened?
An error instead of completing successfully

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.39.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27
PDT 2022; root:xnu-8020.141.5~2/RELEASE_X86_64 x86_64
compiler info: clang: 14.0.0 (clang-1400.0.29.202)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]
pre-commit

Re: bug report

[Eric Sunshine]

On Sun, Dec 25, 2022 at 12:48 PM Eyal Post <eyalpost@gmail.com> wrote:
> 1. I have a script which creates a git worktree and checks out a few
> files from the master branch
> 2. When this script runs "stand alone" - everything works fine
> 3. When this script runs from a "pre-commit" hook it fails with an
> error: "fatal: Unable to create '/tmp/wt-1/.git/index.lock': Not a
> directory"
>
> The content of the script is (simplified example):
> git worktree add /tmp/wt-1 master --no-checkout --detach

This was previously reported[1]. Based upon a quick scan of that old
email thread, I'm not sure we ever came to a final conclusion about
whether Git could address this case itself[2] without breaking
existing workflows or if it should be the hook's responsibility[3].
Perhaps try having your hook script unset environment variables as
explained in [3], or at minimum unset GIT_INDEX_FILE. Also, perhaps
this advice[4] applies and you can take a simpler, less heavyweight
approach to whatever your hook is doing.

[1]: https://lore.kernel.org/git/CAJFQqN+Z9eX6onaj8vVSqpvf-nOC7-Y0Un4NLUie6x6bGfmvZA@mail.gmail.com/
[2]: https://lore.kernel.org/git/20190517011941.GA30372@sigill.intra.peff.net/
[3]: https://lore.kernel.org/git/20190516221702.GA11784@sigill.intra.peff.net/
[4]: https://lore.kernel.org/git/CAGyf7-GtnCqfqPWVpBAELB4xAE6syn7+DfKXgfhL0UoMfvbn4A@mail.gmail.com/

Bug Report

[Jensen Bean]

 H e l l o ,   I   d o w n l o a d e d   g i t   b a s h   2   m o n t
h s   a g o .   E v e r   s i n c e   t h e n   m y   C T R L   b u t
t o n   h a s   n o t   w o r k e d   c o r r e c t l y .   I   k n o
w   t h i s   i s   n o t   a   h a r d w a r e   g l i t c h   b e c
a u s e   t h e   o n l y   t h i n g   t h a t   f i x e s   i t   i
s   u n i n s t a l l i n g   G i t   a n d   a l l   o f   i t   s
a s s o c i a t e d   f i l e s .   A n y   h e l p   o n   t h i s
w o u l d   b e   g r e a t l y   a p p r e c i a t e d .
 J e n s e n

Re: Bug Report

[Bagas Sanjaya]

On 12/8/22 12:29, Jensen Bean wrote:
>  H e l l o ,   I   d o w n l o a d e d   g i t   b a s h   2   m o n t
> h s   a g o .   E v e r   s i n c e   t h e n   m y   C T R L   b u t
> t o n   h a s   n o t   w o r k e d   c o r r e c t l y .   I   k n o
> w   t h i s   i s   n o t   a   h a r d w a r e   g l i t c h   b e c
> a u s e   t h e   o n l y   t h i n g   t h a t   f i x e s   i t   i
> s   u n i n s t a l l i n g   G i t   a n d   a l l   o f   i t   s
> a s s o c i a t e d   f i l e s .   A n y   h e l p   o n   t h i s
> w o u l d   b e   g r e a t l y   a p p r e c i a t e d .
>  J e n s e n

What are your setup? Please try git-bugreport(1) and fill the details.

-- 
An old man doll... just what I always wanted! - Clara

Re: Bug Report

[Bagas Sanjaya]

On 12/25/22 16:02, Jensen Bean wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> What did you do before the bug happened? (Steps to reproduce your issue)
> download git
> What did you expect to happen? (Expected behavior)
> CTRL button to work
> What happened instead? (Actual behavior)
> CTRL button stops working
> What's different between what you expected and what actually happened?
> the CTRL button doesn't work when I have git installed
> Anything else you want to add:
> Deleting git and all its files has been the only thing that works so far
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
> Confusing experience, wasn't sure what to actually do
> 
> [System Info]
> git version:
> git version 2.38.1.windows.1
> cpu: x86_64
> built from commit: b85c8f604d375d4d773a36842964e8a7ec056aae
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Windows 10.0 22621
> compiler info: gnuc: 12.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
> 
> 
> [Enabled Hooks]
> not run from a
> git repository - no hooks to show
> git-bugreport-2022-12-25-0152.txt[+] [unix] (01:52 25/12/2022)
> 

Thanks for the bug report but you need to send it to Git mailing list, in
order for developers there to see the report and act on it.

Also, when replying, don't top-post; reply inline with appropriate context
instead. If you top-post, I'm going to cut the whole context below.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Bug Report

[Jensen Bean]

Hello,



I downloaded Git and Git Bash onto my windows laptop. A few hours
after, I noticed that my CTRL button was not working. I looked online
to see how to fix it. I reinstalled drivers, tried to enable and
disable CTRL shortcuts, turned on the on screen keyboard to see if it
was registering, but nothing has fixed it. The only thing that works
is uninstalling Git, and deleting all files related to it. Once I do
that my CTRL button works again. I can plug in an external keyboard,
but that limits the portability of having a laptop. I tried asking
software developers/engineers, but no one knows. I hope this isn’t a
completely unique case, any help would be greatly appreciated!!



Jensen

Bug report

[Alastair Douglas]

I have found no solution to the issue below. Apologies if it has
already been addressed.

What did you do before the bug happened? (Steps to reproduce your issue)

Have an existing git config with rebase = preserve

What did you expect to happen? (Expected behaviour)

Merges to be preserved when rebasing, without a warning about an option I am
not using.

What happened instead? (Actual behaviour)

I received a warning as though I had used the option on the command line:

warning: git rebase --preserve-merges is deprecated. Use
--rebase-merges instead.

I didn't do that, so I can't follow the advice. There appears to be no
alternative config setting for the new option.

What's different between what you expected and what actually happened?

I expected rebase=preserve to now use --rebase-merges instead of
--preserve-merges, or for a new config setting to be made available to use
--rebase-merges. Ideally the first, because the semantics are clear.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC
2022 x86_64
compiler info: gnuc: 11.2
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /usr/bin/zsh


[Enabled Hooks]
not run from a git repository - no hooks to show

Re: Bug report

[Junio C Hamano]

Alastair Douglas <alastair.douglas@gmail.com> writes:

> I have found no solution to the issue below. Apologies if it has
> already been addressed.

Thanks for a report.  

The solution is to remove "[pull] rebase = preserve" and replace it
with "[pull] rebase = merges", I think.


> What did you do before the bug happened? (Steps to reproduce your issue)
>
> Have an existing git config with rebase = preserve
>
> What did you expect to happen? (Expected behaviour)
>
> Merges to be preserved when rebasing, without a warning about an option I am
> not using.
>
> What happened instead? (Actual behaviour)
>
> I received a warning as though I had used the option on the command line:
>
> warning: git rebase --preserve-merges is deprecated. Use
> --rebase-merges instead.
>
> I didn't do that, so I can't follow the advice. There appears to be no
> alternative config setting for the new option.

It sounds like splitting hairs, but I agree that the message is
misleading.  I think whoever wrote the message meant that "the
feature that is triggered by giving the --preserve-merges option to
the command" was deprecated.  IOW, they did not mean that only the
command line option was depreated, implying that it is not
deprecated to trigger the same feature by setting a configuration
variable.  Both forms of the use of the same feature was deprecated
about the same time.

I also suspect that they were hoping that the users will read the
instruction based on these command line options and understand that
it also applies to the configuration variables.

Re: Bug report

[Alastair Douglas]

On Mon, 3 Oct 2022 at 17:53, Junio C Hamano <gitster@pobox.com> wrote:
>
> Alastair Douglas <alastair.douglas@gmail.com> writes:
>
> > I have found no solution to the issue below. Apologies if it has
> > already been addressed.
>
> Thanks for a report.
>
> The solution is to remove "[pull] rebase = preserve" and replace it
> with "[pull] rebase = merges", I think.
>

Thanks for this reply. This seems to have worked, since I got no warning.

Now that I know it is a new option to the rebase setting I have found
it in the documentation:

branch.<name>.rebase
...
  When merges, pass the --rebase-merges option to git rebase so that
the local merge commits are included in the rebase (see git-rebase(1)
for details).
  When preserve (deprecated in favor of merges), also pass
--preserve-merges along to git rebase so that locally committed merge
commits will not be flattened by running git pull.

It does seem like nobody else on the internet is aware of this, since
I didn't discover this by Googling it.

> I also suspect that they were hoping that the users will read the
> instruction based on these command line options and understand that
> it also applies to the configuration variables.
>

I understood immediately that it applied to the config, but I couldn't
find a single thing about what I *should* have done until you told me
here.

Having said all this, I am fairly sure that I checked the
documentation for the rebase config and failed to spot that new part,
so I am not blameless myself! I feel like *something* could be updated
to point in the right direction, but I really don't know what.
Yesterday, I genuinely thought there was no replacement config for the
deprecated one!

Thanks for your time, but I suppose, in conclusion, there's not a lot
to be done.

Re: Bug report

[Junio C Hamano]

Alastair Douglas <alastair.douglas@gmail.com> writes:

> ... I feel like *something* could be updated
> to point in the right direction, but I really don't know what.

Yes, I shared the exact feeling.  Perhaps the message could have
been a bit more helpful by referring to configuration variables that
are potentially relevant.

Thanks.

Bug Report

[Daniel Habenicht]

Hi there,

I think I found a bug or at least some unexpected behavior. 
Please have a look at the following reproduction repo: 

https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main/README.md



[System Info]
git version:
git version 2.33.1.windows.1
cpu: x86_64
built from commit: 05d80adb775077d673fab685009ede4a1003ed92
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19042 
compiler info: gnuc: 10.3
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]
None

Also reproduced on: 
[System Info] 
git version:
git version 2.35.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.4.0-1074-azure #77~18.04.1-Ubuntu SMP Wed Mar 30 15:36:02 UTC 2022 x86_64
compiler info: gnuc: 9.4
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash


Cheers,
Daniel

Re: Bug Report

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
> Hi there,
> 
> I think I found a bug or at least some unexpected behavior. 
> Please have a look at the following reproduction repo: 
> 
> https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main/README.md

You're more likely to get someone to look at this if you post the actual
text to the list.  While I might be willing to look at it on GitHub,
other folks won't, and I probably won't get a chance to look at this
issue anytime soon.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

RE: Bug Report

[rsbecker]

On April 20, 2022 5:31 PM, brian m. carlson wrote:
>On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
>> Hi there,
>>
>> I think I found a bug or at least some unexpected behavior. Please
>> have a look at the following reproduction repo:
>>
>> https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main
>> /README.md
>
>You're more likely to get someone to look at this if you post the actual text to the
>list.  While I might be willing to look at it on GitHub, other folks won't, and I
>probably won't get a chance to look at this issue anytime soon.

The only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.

Daniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.

--Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.

Re: Bug Report

[Daniel Habenicht]

Hi Randall and Brian, 

thanks for the fast response. 
@Randall: I also tried it with autocrlf=input and it still reproduces. I included it in the reproduction. I also added more examples for confusing behaviour. 


Here is the full bug report: 
(You can view a Markdown rendered version of this reproduction at: https://github.com/DanielHabenicht/bug-reproduction.git-repo)

# Description 

When changing the `.gitattributes` file not all changes to the checked in files are apparent.
They only get updated on a new clone or when refreshing the index - that's somehow expected. 
But it creates confusion and unexpected behavior if they are not updated together with the `.gitattributes` changes. 
It can make easy changes between branches impossible, break the flow of squashing commits or lead to confusing state of everlasting uncommited change.
These edge cases for confusing behaviour I have added below. 

# Reproduction 

1. Checkout with the following `.gitconfig` settings set:

```gitconfig
# .gitconfig
[core]
    autocrlf = false
# Or
    autocrlf = input
```

2. Clone the repository
```bash
git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git
```

3. `test.cs` should be shown as `modified`

> This is confusing to the user, he just checked the repo out and did not change a thing. At least there should be a warning?
   
```
git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   test.cs

no changes added to commit (use "git add" and/or "git commit -a")
```

5. Running any git command like the ones below will not remove the changed file:

```bash
git rm --cached -r .
git reset --hard
git add --renormalize .
```

> This as well is very confusing and there is no indication on why this is happening and there are still modified files after everything should be reset. 
> Keep in mind that this could have happened in error and could be happening to a totally unrelated (to the inital `.gitattributes` change) user. 

6. Running `git diff` is even more confusing, and doing as the warning suggests (`warning: CRLF will be replaced by LF in test.cs. The file will have its original line endings in your working directory`) and replacing `CRLF` by `LF` does silence the warning but does not change the diff itself:

```diff
warning: CRLF will be replaced by LF in test.cs.
The file will have its original line endings in your working directory
diff --git b/test.cs a/test.cs
index 1e230ed..5464a2d 100644
--- b/test.cs
+++ a/test.cs
@@ -1,11 +1,11 @@
-using System.Diagnostics.CodeAnalysis;
-using System.Linq;
-using Xunit;
-using Moq;
-
-
-
-namespace Tests
-{
-
-}
+using System.Diagnostics.CodeAnalysis;^M
+using System.Linq;^M
+using Xunit;^M
+using Moq;^M
+^M
+^M
+^M
+namespace Tests^M
+{^M
+^M
+}^M
```

> This is showing the exact opposite of what git is really doing. Actually it replaces the line encoding of the index (i/crlf) with the right encoding (i/lf) (see **[1]**)
> From the git user perspective everything is in great shape, the file is LF, as it should be, but still git complains about a change that is not visible to the user without background knowledge about gitattributes and the git index. 

8. Try changing the branch to a modified copy with `git checkout some-changes` is not possible (also with the recommended command). The only solution would be to commit - nothing else helps (but thats not really a solution). : 

```bash
error: Your local changes to the following files would be overwritten by checkout:
        test.cs
Please commit your changes or stash them before you switch branches.
Aborting
```

> This makes changing branches harder, as it can't be force reset and git will always complain about files being overwritten.
> It also break the flow for squashing commits as you would need to manually intervene (and add a commit) if someone forgot to commit all files after a .gitattributes change and only recognized it at a later date.


**[1]**: I hope this answer explained it right to me: https://stackoverflow.com/a/71937898/9277073. 
But it is rather unintuitive to me, and possibly other users, as there seems to be a hidden middle layer leading to this problem. See the graph at the github repo)



Cheers,
Daniel




Daniel Habenicht


From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Sent: Thursday, April 21, 2022 00:34
To: 'brian m. carlson' <sandals@crustytoothpaste.net>; 'Daniel Habenicht' <daniel-habenicht@outlook.de>
Cc: git@vger.kernel.org <git@vger.kernel.org>
Subject: RE: Bug Report 
 
On April 20, 2022 5:31 PM, brian m. carlson wrote:
>On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
>> Hi there,
>>
>> I think I found a bug or at least some unexpected behavior. Please
>> have a look at the following reproduction repo:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDanielHabenicht%2Fbug-reproduction.git-repo%2Fblob%2Fmain&amp;data=05%7C01%7C%7C145ae6f595d54ac7b5fd08da231de43c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637860908535410706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=HXFm4sBZ5yQGQPkBlkzKhkgDJOXBqSlgETkrhGxgkmI%3D&amp;reserved=0
>> /README.md
>
>You're more likely to get someone to look at this if you post the actual text to the
>list.  While I might be willing to look at it on GitHub, other folks won't, and I
>probably won't get a chance to look at this issue anytime soon.

The only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.

Daniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.

--Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.

Re: Bug Report

[Torsten Bögershausen]

Hej Daniel,

 $ git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git
 $ cd bug-reproduction.git-repo.git
 $ git ls-files --eol
 i/none  w/none  attr/                   .gitattributes
 i/lf    w/lf    attr/                   README.md
 i/crlf  w/crlf  attr/text eol=lf        test.cs

Your repo needs to be re-normalized:
 $ git add --renormalize .
 $ git status
 On branch main
 Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
          modified:   test.cs

That is all that needs to be done.

Users which are confused may put their frustration aside,
and read the documentation:

https://git-scm.com/docs/gitattributes

especially the part about the line endings and normalization,
search for "renormalize".

I don't know, if there is something we can do that makes live easier,
but if yes: suggestions are more than welcome.

So yes, thanks for the report.




On Thu, Apr 21, 2022 at 01:20:37PM +0000, Daniel Habenicht wrote:
> Hi Randall and Brian, 
>
> thanks for the fast response.
> @Randall: I also tried it with autocrlf=input and it still reproduces. I included it in the reproduction. I also added more examples for confusing behaviour.
>
>
> Here is the full bug report: 
> (You can view a Markdown rendered version of this reproduction at: https://github.com/DanielHabenicht/bug-reproduction.git-repo)
>
> # Description
>
> When changing the `.gitattributes` file not all changes to the checked in files are apparent.
> They only get updated on a new clone or when refreshing the index - that's somehow expected.
> But it creates confusion and unexpected behavior if they are not updated together with the `.gitattributes` changes.
> It can make easy changes between branches impossible, break the flow of squashing commits or lead to confusing state of everlasting uncommited change.
> These edge cases for confusing behaviour I have added below.
>
> # Reproduction
>
> 1. Checkout with the following `.gitconfig` settings set:
>
> ```gitconfig
> # .gitconfig
> [core]
>     autocrlf = false
> # Or
>     autocrlf = input
> ```
>
> 2. Clone the repository
> ```bash
> git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git
> ```
>
> 3. `test.cs` should be shown as `modified`
>
> > This is confusing to the user, he just checked the repo out and did not change a thing. At least there should be a warning?
>
> ```
> git status
> On branch main
> Your branch is up to date with 'origin/main'.
>
> Changes not staged for commit:
>   (use "git add <file>..." to update what will be committed)
>   (use "git restore <file>..." to discard changes in working directory)
>         modified:   test.cs
>
> no changes added to commit (use "git add" and/or "git commit -a")
> ```
>
> 5. Running any git command like the ones below will not remove the changed file:
>
> ```bash
> git rm --cached -r .
> git reset --hard
> git add --renormalize .
> ```
>
> > This as well is very confusing and there is no indication on why this is happening and there are still modified files after everything should be reset.
> > Keep in mind that this could have happened in error and could be happening to a totally unrelated (to the inital `.gitattributes` change) user.
>
> 6. Running `git diff` is even more confusing, and doing as the warning suggests (`warning: CRLF will be replaced by LF in test.cs. The file will have its original line endings in your working directory`) and replacing `CRLF` by `LF` does silence the warning but does not change the diff itself:
>
> ```diff
> warning: CRLF will be replaced by LF in test.cs.
> The file will have its original line endings in your working directory
> diff --git b/test.cs a/test.cs
> index 1e230ed..5464a2d 100644
> --- b/test.cs
> +++ a/test.cs
> @@ -1,11 +1,11 @@
> -using System.Diagnostics.CodeAnalysis;
> -using System.Linq;
> -using Xunit;
> -using Moq;
> -
> -
> -
> -namespace Tests
> -{
> -
> -}
> +using System.Diagnostics.CodeAnalysis;^M
> +using System.Linq;^M
> +using Xunit;^M
> +using Moq;^M
> +^M
> +^M
> +^M
> +namespace Tests^M
> +{^M
> +^M
> +}^M
> ```
>
> > This is showing the exact opposite of what git is really doing. Actually it replaces the line encoding of the index (i/crlf) with the right encoding (i/lf) (see **[1]**)
> > From the git user perspective everything is in great shape, the file is LF, as it should be, but still git complains about a change that is not visible to the user without background knowledge about gitattributes and the git index.
>
> 8. Try changing the branch to a modified copy with `git checkout some-changes` is not possible (also with the recommended command). The only solution would be to commit - nothing else helps (but thats not really a solution). :
>
> ```bash
> error: Your local changes to the following files would be overwritten by checkout:
>         test.cs
> Please commit your changes or stash them before you switch branches.
> Aborting
> ```
>
> > This makes changing branches harder, as it can't be force reset and git will always complain about files being overwritten.
> > It also break the flow for squashing commits as you would need to manually intervene (and add a commit) if someone forgot to commit all files after a .gitattributes change and only recognized it at a later date.
>
>
> **[1]**: I hope this answer explained it right to me: https://stackoverflow.com/a/71937898/9277073.
> But it is rather unintuitive to me, and possibly other users, as there seems to be a hidden middle layer leading to this problem. See the graph at the github repo)
>
>
>
> Cheers,
> Daniel
>
>
>
>
> Daniel Habenicht
>
>
> From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
> Sent: Thursday, April 21, 2022 00:34
> To: 'brian m. carlson' <sandals@crustytoothpaste.net>; 'Daniel Habenicht' <daniel-habenicht@outlook.de>
> Cc: git@vger.kernel.org <git@vger.kernel.org>
> Subject: RE: Bug Report
>  
> On April 20, 2022 5:31 PM, brian m. carlson wrote:
> >On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
> >> Hi there,
> >>
> >> I think I found a bug or at least some unexpected behavior. Please
> >> have a look at the following reproduction repo:
> >>
> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDanielHabenicht%2Fbug-reproduction.git-repo%2Fblob%2Fmain&amp;data=05%7C01%7C%7C145ae6f595d54ac7b5fd08da231de43c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637860908535410706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=HXFm4sBZ5yQGQPkBlkzKhkgDJOXBqSlgETkrhGxgkmI%3D&amp;reserved=0
> >> /README.md
> >
> >You're more likely to get someone to look at this if you post the actual text to the
> >list.  While I might be willing to look at it on GitHub, other folks won't, and I
> >probably won't get a chance to look at this issue anytime soon.
>
> The only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.
>
> Daniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.
>
> --Randall
>
> --
> Brief whoami: NonStop&UNIX developer since approximately
> UNIX(421664400)
> NonStop(211288444200000000)
> -- In real life, I talk too much.

Re: Bug Report

[Torsten Bögershausen]

On Thu, Apr 21, 2022 at 03:29:20PM +0000, Daniel Habenicht wrote:
> Hi Torsten,
>
> thanks for your answer.
> As I explained in the reproduction, I now know why this is happening and I successfully resolved it for my repository.
> I just wanted raise awareness that it is not self-explanatory to non-professional users.
>
> I would suggest two changes:
>
>   1.  Warn the user on commit of the .gitattributes that he also needs to renormalize the repository (or even better, do that by default).
>   2.  Include the information about the need for a renormalization commit on checkouts/restores/reset if there are still files not updated (shown as modified).
>
> Regarding the "Users which are confused may put their frustration aside and read the documentation".
> I think most users won't make the connection for the first 3 google searches, if the problem arises only several commits after the gitattributes change, or if the repository gets cloned by a new user.
>
>
> Cheers,
> Daniel
>

(Sorry for the top-posting before, this list uses bottom-posting)

I still hope that users who are able to find the feature of the
.gitattributes file(s) are able to find out about the renormalaztion as well.
And you are not the first one who runs into this problem, if that is of any
comfort.

Now, back to your suggestions:
The way Git works does not seam to allow a reliable detection of files
that are "modified" after a checkout/restore/reset when .gitattributes
change. (Someone may correct me if this is wrong.
It is related/connected to the timestamps of "the index"
and the files in the working tree and the fact that "git add" will
need to store a new version of the file in the repo e.g CRLF -> LF)

Automatically doing a renormalization seems to be an impossible thing:
The commit as such is atomic, including all files in the working tree
with their line endings and the .gitattributes file itself.
Changing things here seems the wrong way to go, at least for me.

Showing a hint when a .gitattributes file is commited may be more feasable.
I haven't digged which part of the code would be the best place.

Patches and ideas are welcome

Bug Report

[Josh Rampersad]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

Navigated to a non-default branch of the repo.
I wanted a list of tagged commits for a specific tag pattern relating to a
package in my repo.
Ran the command: `git log origin/master --no-walk --grep='my-package' --tags='*my-package*' --decorate-refs='*my-package*'  --format='format:%ct %H %D'`
The output was as expected with the tags not relating to my-package being filtered out from the output by the decorate-refs option.
I then, wanted to pipe this output to a separate program.


What did you expect to happen? (Expected behavior)

I expected that the piped output would be the same as the output in my terminal.

What happened instead? (Actual behavior)

The filtering I got from the decorate-refs flag was no longer being applied. Thus giving me a bunch of tags I did not want

What's different between what you expected and what actually happened?

Whether the decorate-refs option worked as expected.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.31.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT
2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101 x86_64
compiler info: clang: 12.0.0 (clang-1200.0.32.29)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]

bug report

[Theodore Li]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
After cloning a remote repository with the --no-checkout option and
executing git sparse-checkout init, the bug occurs with any
sparse-checkout command with the /* pattern (i.e. git sparse-checkout
set /*).

What did you expect to happen? (Expected behavior)
The contents of .git/info/sparse-checkout and the output of git
sparse-checkout list should be '/*'

What happened instead? (Actual behavior)
Instead, the output is the contents of the user's local root directory
(i.e. /bin, /boot, /cdrom, etc.).

What's different between what you expected and what actually happened?
It should set sparse-checkout to the pattern /*, corresponding to the
remote repository's root directory instead of adding all the folders
and files in the root directory of the user's local machine.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.33.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
compiler info: gnuc: 9.3
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Re: bug report

[Junio C Hamano]

Theodore Li <teddy.litheodore@gmail.com> writes:

> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> After cloning a remote repository with the --no-checkout option and
> executing git sparse-checkout init, the bug occurs with any
> sparse-checkout command with the /* pattern (i.e. git sparse-checkout
> set /*).
>
> What did you expect to happen? (Expected behavior)
> The contents of .git/info/sparse-checkout and the output of git
> sparse-checkout list should be '/*'
>
> What happened instead? (Actual behavior)
> Instead, the output is the contents of the user's local root directory
> (i.e. /bin, /boot, /cdrom, etc.).

A blind guess, as I do not use sparse patterns, but perhaps you did
not quote the "/*' pattern, i.e. you typed

    $ git sparse-checkout set /*

where you would have got a better behaviour if you typed

    $ git sparse-checkout set "/*"

?

Re: bug report

[Theodore Li]

Yes, though other patterns like !/*/ don't need the quotes. I thought
it worked the same way without the quotes in earlier versions, but
after testing with version 2.32.0, it seems like the behavior is the
same. Guess I remembered wrong.

On Thu, Nov 11, 2021 at 11:30 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Theodore Li <teddy.litheodore@gmail.com> writes:
>
> > Thank you for filling out a Git bug report!
> > Please answer the following questions to help us understand your issue.
> >
> > What did you do before the bug happened? (Steps to reproduce your issue)
> > After cloning a remote repository with the --no-checkout option and
> > executing git sparse-checkout init, the bug occurs with any
> > sparse-checkout command with the /* pattern (i.e. git sparse-checkout
> > set /*).
> >
> > What did you expect to happen? (Expected behavior)
> > The contents of .git/info/sparse-checkout and the output of git
> > sparse-checkout list should be '/*'
> >
> > What happened instead? (Actual behavior)
> > Instead, the output is the contents of the user's local root directory
> > (i.e. /bin, /boot, /cdrom, etc.).
>
> A blind guess, as I do not use sparse patterns, but perhaps you did
> not quote the "/*' pattern, i.e. you typed
>
>     $ git sparse-checkout set /*
>
> where you would have got a better behaviour if you typed
>
>     $ git sparse-checkout set "/*"
>
> ?

Re: bug report

[Paul Smith]

On Fri, 2021-11-12 at 01:59 -0500, Theodore Li wrote:
> Yes, though other patterns like !/*/ don't need the quotes. I thought
> it worked the same way without the quotes in earlier versions, but
> after testing with version 2.32.0, it seems like the behavior is the
> same. Guess I remembered wrong.

It's important to realize that in a POSIX-style shell (as you'll find
on GNU/Linux or MacOS, or in the Git for Windows shell), wildcard
expansion is performed _by the shell_ before the program is even
invoked.  It's not performed by the program itself (in this case, Git).

In a POSIX-style shell it works like this (by default): first the shell
will try to expand the wildcards in your command line by matching them
for files.  If any match, the wildcard expression is replaced on the
command line.  If no files match, then the wildcard expression is
passed to the command without change.

So if you run:

  git sparse-checkout /*

then the shell will check if any files match the wildcard /*: since
clearly you will get matches for this expression, they will be expanded
and the shell will actually run:

  git sparse-checkout /bin /boot /cdrom /dev /...

Note, Git does not receive any indication that there ever was a
wildcard expression here!

On the other hand if you run:

  git sparse-checkout /blah/*/blah

(assuming you don't have any files on your system that match this
wildcard) then it won't match and the shell will run:

  git sparse-checkout /blah/*/blah

Now Git can examine this wildcard and do an appropriate thing with it.

In short, if you want to be _sure_ that a wildcard expression is passed
to the command and not expanded by the shell, you must always quote it:

  git sparse-checkout "/*"

If you don't quote it then it may or may not do what you intended,
depending on whether the wildcard happens to match any files.

Bug Report

[James Yeoman]

gitk and git-gui are both not respecting git config.

When I set the diff.algorithm global config to patience, the command
line git respects the config. However, both gitk and git-gui don't.
When I use "git status -vv" to get a diff of the working directory,
the diff produced respects the algorithm choice. The diff of the
working directory in gitk and git-gui both still use the default diff
algorithm, rather than the algorithm from the config.

-- 

Re: Bug Report

[Pratyush Yadav]

Hi James,

On 27/03/20 11:53AM, James Yeoman wrote:
> gitk and git-gui are both not respecting git config.
> 
> When I set the diff.algorithm global config to patience, the command
> line git respects the config. However, both gitk and git-gui don't.
> When I use "git status -vv" to get a diff of the working directory,
> the diff produced respects the algorithm choice. The diff of the
> working directory in gitk and git-gui both still use the default diff
> algorithm, rather than the algorithm from the config.
 
Thanks for reporting. Can you please send steps to produce a simple 
scenario where the diff from two algorithms is different so I can test 
why git-gui is not respecting the config. Make them as minimal as 
possible.

Also, +Cc Paul, the gitk maintainer.

-- 
Regards,
Pratyush Yadav

bug report

[aaa]

Dear sir:
    I have followed the instructions"To set up software RDMA on an existing interface with either of the available drivers, use the following commands, substituting <DRIVER> with the name of the driver of your choice (rdma_rxe or siw) and <TYPE> with the type corresponding to the driver (rxe or siw).
# modprobe <DRIVER>
# rdma link add <NAME> type <TYPE> netdev <DEVICE>

Please note that you need version of iproute2 recent enough is required for the command above to work.
You can use either ibv_devices or rdma link to verify that the device was successfully added."
but when I execute rdma link add, it cann't find the command, so how can i solve it. Thank you very much!
my commands history is showed as below.




zhums@zhums-virtual-machine:~/rdma-core/providers/rxe/man$ rdma link add
未找到 'rdma' 命令，您要输入的是否是：
 命令 'dma' 来自于包 'dma' (universe)
rdma：未找到命令
zhums@zhums-virtual-machine:~/rdma-core/providers/rxe/man$ modprobe 
modprobe: ERROR: missing parameters. See -h.
zhums@zhums-virtual-machine:~/rdma-core/providers/rxe/man$ modprobe rdma_rxe
zhums@zhums-virtual-machine:~/rdma-core/providers/rxe/man$ modinfo rdma_rxe
filename:       /lib/modules/4.15.0-88-generic/kernel/drivers/infiniband/sw/rxe/rdma_rxe.ko
license:        Dual BSD/GPL
description:    Soft RDMA transport
author:         Bob Pearson, Frank Zago, John Groves, Kamal Heib
srcversion:     3301C3D016E893C3F327B14
depends:        ib_core,ip6_udp_tunnel,udp_tunnel
retpoline:      Y
intree:         Y
name:           rdma_rxe
vermagic:       4.15.0-88-generic SMP mod_unload 
parm:           add:Create RXE device over network interface
parm:           remove:Remove RXE device over network interface
zhums@zhums-virtual-machine:~/rdma-core/providers/rxe/man$ sudo apt-get install iproute2
正在读取软件包列表... 完成
正在分析软件包的依赖关系树       
正在读取状态信息... 完成       
iproute2 已经是最新版 (4.3.0-1ubuntu3.16.04.5)。






  
 
   
 



 


 

Re: bug report

[Leon Romanovsky]

On Sat, Mar 21, 2020 at 05:38:22PM +0800, aaa wrote:
>
>
>
>
>
>
>
> Dear sir:
>     I have followed the instructions"To set up software RDMA on an existing interface with either of the available drivers, use the following commands, substituting <DRIVER> with the name of the driver of your choice (rdma_rxe or siw) and <TYPE> with the type corresponding to the driver (rxe or siw).
> # modprobe <DRIVER>
> # rdma link add <NAME> type <TYPE> netdev <DEVICE>
>
> Please note that you need version of iproute2 recent enough is required for the command above to work.
> You can use either ibv_devices or rdma link to verify that the device was successfully added."
> but when I execute rdma link add, it cann't find the command, so how can i solve it. Thank you very much!
> my commands history is showed as below.

The solution is written in the first sentence "Please note that you need version
of iproute2 recent enough is required for the command above to work."

Thanks

Re: bug report

[Nick Steinhauser]

user$ git checkout -b "environment-logging"
Switched to a new branch ' environment-logging'
user$ git status
On branch  environment-logging
nothing to commit, working tree clean
user$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
user$ git branch -D environment-logging
error: branch 'environment-logging' not found.


Regular space:
user$ git branch -D " environment-logging"
error: branch ' environment-logging' not found.


Nonbreaking space:
user$ git branch -D " environment-logging"
Deleted branch  environment-logging (was 267ffff).


Non breaking space inserted into my branch name. Above is copy pasted
from terminal with only the user name and directory altered and
extraneous commands removed. Note the space in the std out of the
first command but not included in the command itself. Whereas in the
last command I explicitly typed the nonbreaking space and it does
appear as a visible space. I do not know how to reproduce.


Thanks,

Nick

Bug report

[李 武刚]

[-- Attachment #1.1: Type: text/plain, Size: 272 bytes --]


Hi, ALL

There is one bug which has not checking the result value of  hashtab_search in the function define_level of policydb_define.c. If the category is not defined, a null-pointer dereference will be taken place.
The patch is attached.

Best Regards,
李武刚


[-- Attachment #1.2: Type: text/html, Size: 1796 bytes --]

[-- Attachment #2: 0001-checkpolicy-check-the-result-value-of-hashtable_sear.patch --]
[-- Type: application/octet-stream, Size: 835 bytes --]

From 1e778137817bed108cc7c7c4889303a3f76ccd27 Mon Sep 17 00:00:00 2001
From: liwugang <liwugang@xiaomi.com>
Date: Sat, 8 Sep 2018 17:16:41 +0800
Subject: [PATCH] checkpolicy: check the result value of hashtable_search

Signed-off-by: liwugang <liwugang@xiaomi.com>
---
 checkpolicy/policy_define.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/checkpolicy/policy_define.c b/checkpolicy/policy_define.c
index d8788a6f..ece10e7a 100644
--- a/checkpolicy/policy_define.c
+++ b/checkpolicy/policy_define.c
@@ -1107,6 +1107,11 @@ int define_level(void)
 			    (cat_datum_t *) hashtab_search(policydbp->p_cats.
 							   table,
 							   (hashtab_key_t) id);
+			if (!cdatum) {
+				yyerror2("unknown category %s", id);
+				free(id);
+				return -1;
+			}
 			range_start = range_end = cdatum->s.value - 1;
 		}
 
-- 
2.18.0

Re: Bug report

[Nicolas Iooss]

On Mon, Sep 10, 2018 at 2:46 PM 李 武刚 <liwugang@outlook.com> wrote:
> Hi, ALL
>
> There is one bug which has not checking the result value of  hashtab_search in the function define_level of policydb_define.c. If the category is not defined, a null-pointer dereference will be taken place.
>
> The patch is attached.
>
Hi,
Thanks for your bugfix. It looks good to me and as no one complained,
I have merged it.

By the way, if you want to submit more patches, please send them
inline and not as attachment (with "git send-email" for example). This
makes the review easier.

Nicolas

Bug report

[Jianliang Wu]

Hi,

Since it's my first time to report a bug for open source software,
could anyone give me a hint about the procedure of reporting a bluez
bug?
I've searched the BlueZ issues tracker but I found nothing. Or should
I report to different Linux distros?

Thanks,
Allen

Re: Bug report

[Luiz Augusto von Dentz]

Hi Allen,

On Thu, Sep 6, 2018 at 11:23 PM, Jianliang Wu <johnjianliangwu@gmail.com> wrote:
> Hi,
>
> Since it's my first time to report a bug for open source software,
> could anyone give me a hint about the procedure of reporting a bluez
> bug?
> I've searched the BlueZ issues tracker but I found nothing. Or should
> I report to different Linux distros?

Do you care to describe what is the bug, maybe it is trivial enough we
can just handle it over email.

-- 
Luiz Augusto von Dentz

Bug report

[Aleksandar Pavic]

  I have a file

  app/Controller/CustomerCardVerificationController.php

And when I take a look at changes log, I get this (no matter which tool 
I use):

2017-07-31 19:41 dule             o membership renew payment email
2017-06-07 08:59 Dusan Tatic      o cc refund clean
2017-04-15 00:16 Miodrag Dragić   o refound admin payment
2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
2017-03-16 15:59 Aleksandar Pavic o paypal
2017-03-10 13:34 Aleksandar Pavic o Production branch
2017-03-10 13:01 Aleksandar Pavic I Migrating dev

However if I manually browse thru revisions and open revision from 
03/27/2017 07:05 PM

I can see the change in that file which is unlisted above, at revision 
ff9f4946e109bd234d438e4db1d319b1f6cb6580

And I'm at master branch all the time...

We wouldn't have noticed that if it weren't one important feature...

Re: Bug report

[Kevin Daudt]

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>  I have a file
> 
>  app/Controller/CustomerCardVerificationController.php
> 
> And when I take a look at changes log, I get this (no matter which tool I
> use):
> 
> 2017-07-31 19:41 dule             o membership renew payment email
> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
> 2017-03-16 15:59 Aleksandar Pavic o paypal
> 2017-03-10 13:34 Aleksandar Pavic o Production branch
> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
> 
> However if I manually browse thru revisions and open revision from
> 03/27/2017 07:05 PM
> 
> I can see the change in that file which is unlisted above, at revision
> ff9f4946e109bd234d438e4db1d319b1f6cb6580
> 
> And I'm at master branch all the time...
> 
> We wouldn't have noticed that if it weren't one important feature...
> 

What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
return?

Where did you find this commit?

Re: Bug report

[Dov Grobgeld]

The following answer that I got back in 2015 from Jeff King might be
relevant to your problem:

https://marc.info/?l=git&m=144178948506788&w=2

Regards,
Dov

On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt <me@ikke.info> wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>  I have a file
>>
>>  app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:41 dule             o membership renew payment email
>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>
>> However if I manually browse thru revisions and open revision from
>> 03/27/2017 07:05 PM
>>
>> I can see the change in that file which is unlisted above, at revision
>> ff9f4946e109bd234d438e4db1d319b1f6cb6580
>>
>> And I'm at master branch all the time...
>>
>> We wouldn't have noticed that if it weren't one important feature...
>>
>
> What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
> return?
>
> Where did you find this commit?

Re: Bug report

[Aleksandar Pavic]

Hm, thanks, but the link was not helpful, there are no merge commits to 
master branch.

Those changes should have not been undone, that's how we caught it, 
because 1 line peace of code introduced new feature (+-10% tolerance on 
credit card verification  amount).

So most likeley they were undone, but our tree is pretty simple, we have 
master and production branches.



On 31.08.2017. 16:19, Dov Grobgeld wrote:
> The following answer that I got back in 2015 from Jeff King might be
> relevant to your problem:
>
> https://marc.info/?l=git&m=144178948506788&w=2
>
> Regards,
> Dov
>
> On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt <me@ikke.info> wrote:
>> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>>   I have a file
>>>
>>>   app/Controller/CustomerCardVerificationController.php
>>>
>>> And when I take a look at changes log, I get this (no matter which tool I
>>> use):
>>>
>>> 2017-07-31 19:41 dule             o membership renew payment email
>>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>>
>>> However if I manually browse thru revisions and open revision from
>>> 03/27/2017 07:05 PM
>>>
>>> I can see the change in that file which is unlisted above, at revision
>>> ff9f4946e109bd234d438e4db1d319b1f6cb6580
>>>
>>> And I'm at master branch all the time...
>>>
>>> We wouldn't have noticed that if it weren't one important feature...
>>>
>> What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
>> return?
>>
>> Where did you find this commit?

Re: Bug report

[Stephan Beyer]

On 08/31/2017 08:36 AM, Kevin Daudt wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>  I have a file
>>
>>  app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:41 dule             o membership renew payment email
>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>
>> However if I manually browse thru revisions and open revision from
>> 03/27/2017 07:05 PM
>>
>> I can see the change in that file which is unlisted above, at revision
>> ff9f4946e109bd234d438e4db1d319b1f6cb6580

I am not sure if I fully understand but I guess your commit ff9f4946e1
has been commited at detached HEAD.

You could do
	git log --oneline --graph master ff9f4946e1
to see where the "missing" commit lies.
And probably a
	git cherry-pick ff9f4946e1
might pick your missing feature.

Stephan

Re: Bug report

[Jeff King]

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:

>  I have a file
> 
>  app/Controller/CustomerCardVerificationController.php
> 
> And when I take a look at changes log, I get this (no matter which tool I
> use):
> 
> 2017-07-31 19:41 dule             o membership renew payment email
> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
> 2017-03-16 15:59 Aleksandar Pavic o paypal
> 2017-03-10 13:34 Aleksandar Pavic o Production branch
> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>
> However if I manually browse thru revisions and open revision from
> 03/27/2017 07:05 PM
> 
> I can see the change in that file which is unlisted above, at revision
> ff9f4946e109bd234d438e4db1d319b1f6cb6580

How are you invoking the log? Are you doing:

  git log app/Controller/CustomerCardVerificationController.php

or similar? If that is the case, then history simplification may be
causing the results you see. And even you don't _see_ any merges in the
output, that is because they were simplified away. And the commit you
are looking for may have been on a side branch that was simplified away.

If you do:

  git log --full-history app/...

does the commit you are interested in show up? If so, then it was
removed due to history simplification. And if you are surprised that a
side branch was simplified away, that is most likely because there is a
mis-merge in your history (some merge which threw away the changes on a
side branch).

Try:

  git log --graph --oneline --name-status --full-history app/...

to see the whole shape of history, including which commits touched the
file.

You can read more about it in the "History Simplification" section of
"git help log".

-Peff

Bug report

[Ing. Ricardo Brisighelli]

Hi my name is Richard and i suscribe to this list but dont know if this list 
is for reports bugs.

Tnks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Bug report

[Wei Liu]

On Thu, Dec 22, 2016 at 05:07:58PM -0300, Ing. Ricardo Brisighelli wrote:
> Hi my name is Richard and i suscribe to this list but dont know if this list 
> is for reports bugs.
> 

Yes. Please read
https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen

Wei.

> Tnks
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

bug report

[李本超]

Hi all,

      Yestoday when I worked using Git, I found a bug. It's about
rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
problem:

      There is a master branch, and we develop in our own branch.
Let's simplify this: there are two branches created at the same commit
point at master. Then branch A add a function X. Branch B add funciton
X too (yes, they are very same). Then branch B modify function X to
function Y.
      Branch A finishes it's job first and merged to master
successfully and happily without any conflicts. When branch B wants to
merge to master, he finds that master has updated. So branch B must
rebase to the current master. Then problem happends: git rebase
successfully without any conflicts. But branch B cannot see function X
from master (or branch A), only its own function Y.
      I think that's because Git is based on file instead of patch.
But I think Git can report it in this situation.
      How do you think ? Thank you anyway for maintaining this amazing software.

-- 

Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

Re: bug report

[Pranit Bauva]

Please mention the version no of git you are using and your system.
I am answering according to git 2.8.1 Lubuntu 15.04

On Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:
> Hi all,
>
>       Yestoday when I worked using Git, I found a bug. It's about
> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
> problem:
>
>       There is a master branch, and we develop in our own branch.
> Let's simplify this: there are two branches created at the same commit
> point at master. Then branch A add a function X. Branch B add funciton
> X too (yes, they are very same). Then branch B modify function X to
> function Y.

What do you mean by this? Did you amend the previous commit, or
introduced another separate commit ?

>       Branch A finishes it's job first and merged to master
> successfully and happily without any conflicts. When branch B wants to
> merge to master, he finds that master has updated. So branch B must
> rebase to the current master. Then problem happends: git rebase
> successfully without any conflicts. But branch B cannot see function X
> from master (or branch A), only its own function Y.
>       I think that's because Git is based on file instead of patch.
> But I think Git can report it in this situation.
>       How do you think ? Thank you anyway for maintaining this amazing software.

Well I tried to reproduce the problem. I did the following steps:
$ mdkir test_repo
$ cd test_repo
$ git init
$ echo Hello >hi
$ git commit -a -m "C1"
$ git checkout -b A
$ echo Bye >hi
$ git commit -a -m "C2 - A"
$ git checkout -
$ git checkout -b B
$ echo "Bye." >hi
$ git commit -a -m "C3 - B"
$ git checkout -
$ git merge A
$ git checkout B
$ git rebase master

This shows that some merge conflicts needs resolving. Did I follow
your steps or I missed something? It would be better if you could
reproduce your steps like I did so as to make things more clear to us.

Regards,
Pranit Bauva

Re: bug report

[李本超]

git version 2.6.4 (Apple Git-63)
system version: OS X EI Capitan 10.11.4

below is the steps:
$ mkdir test_repo
$ cd test_repo
$ git init
$ echo "hello" > README.md
$ git commit -a -m 'Add README.md'

$ git checkout -b A
$ echo "world" > README.md
$ git commit -a -m 'Add one line'

$ git checkout master
$ git checkout -b B
$ echo "world" > README.md
$ git commit -a -m 'Add one line too'
$ [midify 'world' line to other things like 'git' using vi]
$ git commit -a -m 'Modify one line'

$ git checkout master
$ git merge A

$ git checkout B
$ git rebase master [problem is here, cat README.rd we will get :
hello and git instead of hello world git]

2016-05-13 13:23 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> Please mention the version no of git you are using and your system.
> I am answering according to git 2.8.1 Lubuntu 15.04
>
> On Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:
>> Hi all,
>>
>>       Yestoday when I worked using Git, I found a bug. It's about
>> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
>> problem:
>>
>>       There is a master branch, and we develop in our own branch.
>> Let's simplify this: there are two branches created at the same commit
>> point at master. Then branch A add a function X. Branch B add funciton
>> X too (yes, they are very same). Then branch B modify function X to
>> function Y.
>
> What do you mean by this? Did you amend the previous commit, or
> introduced another separate commit ?
>
>>       Branch A finishes it's job first and merged to master
>> successfully and happily without any conflicts. When branch B wants to
>> merge to master, he finds that master has updated. So branch B must
>> rebase to the current master. Then problem happends: git rebase
>> successfully without any conflicts. But branch B cannot see function X
>> from master (or branch A), only its own function Y.
>>       I think that's because Git is based on file instead of patch.
>> But I think Git can report it in this situation.
>>       How do you think ? Thank you anyway for maintaining this amazing software.
>
> Well I tried to reproduce the problem. I did the following steps:
> $ mdkir test_repo
> $ cd test_repo
> $ git init
> $ echo Hello >hi
> $ git commit -a -m "C1"
> $ git checkout -b A
> $ echo Bye >hi
> $ git commit -a -m "C2 - A"
> $ git checkout -
> $ git checkout -b B
> $ echo "Bye." >hi
> $ git commit -a -m "C3 - B"
> $ git checkout -
> $ git merge A
> $ git checkout B
> $ git rebase master
>
> This shows that some merge conflicts needs resolving. Did I follow
> your steps or I missed something? It would be better if you could
> reproduce your steps like I did so as to make things more clear to us.
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

Re: bug report

[Pranit Bauva]

On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:
> git version 2.6.4 (Apple Git-63)
> system version: OS X EI Capitan 10.11.4
>
> below is the steps:
> $ mkdir test_repo
> $ cd test_repo
> $ git init
> $ echo "hello" > README.md
> $ git commit -a -m 'Add README.md'

It was my mistake. git-commit -a adds files which are tracked.
Currently README.md is not tracked. So you will have to first use
git-add to add them for tracking. Though while trying out your steps I
used git-add. For further commits one can use -a with git-commit.

> $ git checkout -b A
> $ echo "world" > README.md
> $ git commit -a -m 'Add one line'

You are technically not adding a line. You are modifying the previous
line to the updated line. So the contents of the file will be:
"world"
It seems from the further part that you actually wanted to add the
line rather than modifying it. Better to use ">>" instead of ">". ">>"
is used for appending.

> $ git checkout master
> $ git checkout -b B
> $ echo "world" > README.md
> $ git commit -a -m 'Add one line too'
> $ [midify 'world' line to other things like 'git' using vi]

I think you mean modify.

> $ git commit -a -m 'Modify one line'
>
> $ git checkout master
> $ git merge A
>
> $ git checkout B
> $ git rebase master [problem is here, cat README.rd we will get :
> hello and git instead of hello world git]

The git behavior is quite correct.
When you are on the B branch and you choose to rebase it on the
master, it will apply commits as patches. So it first sees that the
commit on the A branch which is now merged with master ie. "Add one
line" and the commit on the B branch "Add one line too" are doing the
same thing which is removing the line "hello" and adding the line
"world". Then it applies the commit "modify one line" on top of this
which removes the line "world" and adds the line "git". So finally,
README.md will contain only "git".

Regards,
Pranit Bauva

Re: bug report

[李本超]

Yes, you got the right understanding of my problem.

You are right, the git behavior is quite correct. But I met this
problem in my practical work:

My colleague added a method but I didn't know. I also added the same method.
Then I found that I didn't need the method actually, so I deleted it.
My colleague merged to the master before me. When I wanted to merge, I found
conflicts with master. And I rebased to current master. And That method was
deleted finally without any warning or information.

Do you think Git should output something to warn the user or I just
use Git in a wrong way ?

Thanks.

2016-05-13 14:37 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:
>> git version 2.6.4 (Apple Git-63)
>> system version: OS X EI Capitan 10.11.4
>>
>> below is the steps:
>> $ mkdir test_repo
>> $ cd test_repo
>> $ git init
>> $ echo "hello" > README.md
>> $ git commit -a -m 'Add README.md'
>
> It was my mistake. git-commit -a adds files which are tracked.
> Currently README.md is not tracked. So you will have to first use
> git-add to add them for tracking. Though while trying out your steps I
> used git-add. For further commits one can use -a with git-commit.
>
>> $ git checkout -b A
>> $ echo "world" > README.md
>> $ git commit -a -m 'Add one line'
>
> You are technically not adding a line. You are modifying the previous
> line to the updated line. So the contents of the file will be:
> "world"
> It seems from the further part that you actually wanted to add the
> line rather than modifying it. Better to use ">>" instead of ">". ">>"
> is used for appending.
>
>> $ git checkout master
>> $ git checkout -b B
>> $ echo "world" > README.md
>> $ git commit -a -m 'Add one line too'
>> $ [midify 'world' line to other things like 'git' using vi]
>
> I think you mean modify.
>
>> $ git commit -a -m 'Modify one line'
>>
>> $ git checkout master
>> $ git merge A
>>
>> $ git checkout B
>> $ git rebase master [problem is here, cat README.rd we will get :
>> hello and git instead of hello world git]
>
> The git behavior is quite correct.
> When you are on the B branch and you choose to rebase it on the
> master, it will apply commits as patches. So it first sees that the
> commit on the A branch which is now merged with master ie. "Add one
> line" and the commit on the B branch "Add one line too" are doing the
> same thing which is removing the line "hello" and adding the line
> "world". Then it applies the commit "modify one line" on top of this
> which removes the line "world" and adds the line "git". So finally,
> README.md will contain only "git".
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

Re: bug report

[Pranit Bauva]

On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:
> Yes, you got the right understanding of my problem.
>
> You are right, the git behavior is quite correct. But I met this
> problem in my practical work:
>
> My colleague added a method but I didn't know. I also added the same method.
> Then I found that I didn't need the method actually, so I deleted it.
> My colleague merged to the master before me. When I wanted to merge, I found
> conflicts with master. And I rebased to current master. And That method was
> deleted finally without any warning or information.

I am quite sure that there would be an output to show that there are
conflicts and it would be suggesting you to first resolve the
conflicts and there would also be markers in the file like ">>>>>" and
"======" and the file would be marked with "both modified". After you
resolve the conflicts, you can add the file by using git-add and then
"git rebase --continue" to proceed. If you find out that there is some
problem, then you can always use "git rebase --abort" to abort the
rebase process and get to the initial state *perfectly* without any
glitches.

> Do you think Git should output something to warn the user or I just
> use Git in a wrong way ?

It does warn. I don't know how it got missed in your case. This is
quite a common problem and even I have faced this quite for quite a
lot of times now and it always did warn me.

> Thanks.

I will recommend you reading this article[1]. I know its a bit of a
long read but it will help a lot.

[1]: http://tedfelix.com/software/git-conflict-resolution.html

Regards,
Pranit Bauva

Re: bug report

[李本超]

It does not warn me in this case. I replayed it again, below is my process:

$ mkdir bug_test
$ cd bug_test/
$ git init
Initialized empty Git repository in /home/libenchao/tmp/bug_test/.git/
$ echo 'hello' > README.md
$ git add README.md
$ git commit -m 'Add README.md'
[master (root-commit) 9cdb3a8] Add README.md
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
$ git checkout -b A
Switched to a new branch 'A'
$ echo 'world' >> README.md
$ git commit -a -m 'Add one line'
[A 6f0b0a3] Add one line
 1 file changed, 1 insertion(+)
$ git checkout master
Switched to branch 'master'
$ git checkout -b B
Switched to a new branch 'B'
$ echo 'world' >> README.md
$ git commit -a -m 'Add one line too'
[B d89cf11] Add one line too
 1 file changed, 1 insertion(+)
$ vim README.md                        # in this line, I modify line 2
'world' to 'git'
$ cat README.md
hello
git
$ git commit -a -m 'Modify one line'
[B a674427] Modify one line
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git checkout master
Switched to branch 'master'
$ git merge A
Updating 9cdb3a8..6f0b0a3
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)
$ git checkout B
Switched to branch 'B'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Modify one line
$ cat README.md
hello
git
$

2016-05-13 15:10 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:
>> Yes, you got the right understanding of my problem.
>>
>> You are right, the git behavior is quite correct. But I met this
>> problem in my practical work:
>>
>> My colleague added a method but I didn't know. I also added the same method.
>> Then I found that I didn't need the method actually, so I deleted it.
>> My colleague merged to the master before me. When I wanted to merge, I found
>> conflicts with master. And I rebased to current master. And That method was
>> deleted finally without any warning or information.
>
> I am quite sure that there would be an output to show that there are
> conflicts and it would be suggesting you to first resolve the
> conflicts and there would also be markers in the file like ">>>>>" and
> "======" and the file would be marked with "both modified". After you
> resolve the conflicts, you can add the file by using git-add and then
> "git rebase --continue" to proceed. If you find out that there is some
> problem, then you can always use "git rebase --abort" to abort the
> rebase process and get to the initial state *perfectly* without any
> glitches.
>
>> Do you think Git should output something to warn the user or I just
>> use Git in a wrong way ?
>
> It does warn. I don't know how it got missed in your case. This is
> quite a common problem and even I have faced this quite for quite a
> lot of times now and it always did warn me.
>
>> Thanks.
>
> I will recommend you reading this article[1]. I know its a bit of a
> long read but it will help a lot.
>
> [1]: http://tedfelix.com/software/git-conflict-resolution.html
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

Re: bug report

[Jeff King]

On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:

> It does not warn me in this case. I replayed it again, below is my process:
> 
> [...setup...]

So after you setup steps you have:

  $ git log --decorate --oneline --raw

  * a3ce3bc (HEAD -> B) modify
  | :100644 100644 94954ab... 23509e0... M        README.md
  * ef702eb add one line too
  | :100644 100644 ce01362... 94954ab... M        README.md
  | * fa8b99e (master, A) add one line
  |/  
  |   :100644 100644 ce01362... 94954ab... M      README.md
  * cf2103b add readme
    :000000 100644 0000000... ce01362... A        README.md

Note that B^ (ef702eb) and A (fa8b99e) introduce the exact same change
(moving README.md from ce01362 to 94954ab). And master is at the same
commit as A (due to your fast-forward merge earlier).

So now when you run:

> $ git rebase master

Git will try to replay the commits on master..B on top of master, in
order.  Those commits are ef702eb and a3ce3bc (your commit names will
differ, because your name and timestamps will differ).

So it replays the first one, and sees that it the patch is a noop[1];
the tree in master already has the same end state. So we skip the patch.
And then we replay the second one, which applies cleanly.

The moment where I think you'd like to be notified is when we skipped
doing anything with patch 1. You'd prefer it to say "woah, the other
side of the rebase did the same thing as us".

But rebase does not do that by default, because the intent of rebase is
that you are rebasing your work on an upstream which might be accepting
part of your work as patches. So it is a feature that rebase says
"already applied upstream -- let's ignore this one".

I don't think there is a way to ask rebase not to ignore such
already-applied patches. But I'm not sure if there should be, for two
reasons:

  1. You should consider just using "git merge" to merge the two
     branches. That preserves more information about what actually
     happened, and would find a conflict in a case like this.

  2. Even with merging, you cannot assume that the end result is sane.
     In your example, there is a textual conflict. But you can easily
     come up with other examples where a merge is textually sound, but
     has some semantic conflict (e.g., you update the signature of a
     function but a colleague adds another call to it using the old
     signature).

     You have to examine and test the results of merges for sanity. And
     likewise with rebases.

-Peff

[1] Actually, rebase does not even try to replay the first patch. When
    it generates the list of commits, it ignores any whose "patch-id" is
    the same as a commit on the other side. But the end effect is the
    same.

Re: bug report

[李本超]

Thanks for your explanation

>
> The moment where I think you'd like to be notified is when we skipped
> doing anything with patch 1. You'd prefer it to say "woah, the other
> side of the rebase did the same thing as us".
Actually this is the problem where I want to be notified.

> But rebase does not do that by default, because the intent of rebase is
> that you are rebasing your work on an upstream which might be accepting
> part of your work as patches. So it is a feature that rebase says
> "already applied upstream -- let's ignore this one".
>
> I don't think there is a way to ask rebase not to ignore such
> already-applied patches. But I'm not sure if there should be, for two
> reasons:
>
>   1. You should consider just using "git merge" to merge the two
>      branches. That preserves more information about what actually
>      happened, and would find a conflict in a case like this.
>
>   2. Even with merging, you cannot assume that the end result is sane.
>      In your example, there is a textual conflict. But you can easily
>      come up with other examples where a merge is textually sound, but
>      has some semantic conflict (e.g., you update the signature of a
>      function but a colleague adds another call to it using the old
>      signature).
>
>      You have to examine and test the results of merges for sanity. And
>      likewise with rebases.
>
> -Peff
>
> [1] Actually, rebase does not even try to replay the first patch. When
>     it generates the list of commits, it ignores any whose "patch-id" is
>     the same as a commit on the other side. But the end effect is the
>     same.
Your explanation looks reasonable to me.

Thanks a lot for your time and patience. And @Pranit Bauva too.

By the way, many thanks for maintaining this outstanding software Git.


-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

Bug Report

[Benjamin Sandeen]

Today, I managed to create a duplicate branch in a git repository.  While
this may not be a bug per se, I do think that it is confusing and some way
of preventing such issues in the future may be helpful.

I first cloned the repository:

$ git clone https://github.com/CodeForChicago/superclass.git

Then, I created a new branch (or so I thought):

$ git checkout -b lesson_page

However, this branch has already existed for about 4 weeks, without my
knowledge.  I proceeded to do some work on the files it contained, and when
it came time to commit and push, and when I pushed, I got the following
message:

To https://github.com/CodeForChicago/superclass.git
 ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
error: failed to push some refs to '
https://github.com/CodeForChicago/superclass.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Given that I had believed that I had created the branch just a few hours
prior and was the first to attempt to push to it, this error was
consternating.

I may be wrong (I am aware that my understanding of git is limited), but I
believe that the git checkout -b command is simply supposed to create a new
branch and then switch to it (I'm not aware of any subtle behavior that goes
on behind the scenes if the "new" branch that the user is attempting to
create already exists).  This is why I said it "may not be a bug per se".
However, I expect most people who use git to expect this command to create a
new branch and then switch to it (this is what most sources online will tell
users to do to create a new branch), and as such, it would be extremely
beneficial if git were to, at the very least, alert the user to the conflict
in some way or another.

Thanks,
Ben

Lead Consultant, Northwestern University Information Technology
Research Assistant, Center for Interdisciplinary Exploration and Research in
Astrophysics at Northwestern University
Phsyics, Weinberg College of Arts and Sciences
Computer Science, Weinberg College of Arts and Sciences
Classics, Weinberg College of Arts and Sciences

Re: Bug Report

[Eric N. Vander Weele]

On Sat, Apr 2, 2016 at 8:25 PM, Benjamin Sandeen
<benjaminsandeen2016@u.northwestern.edu> wrote:
> Today, I managed to create a duplicate branch in a git repository.  While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.

This can be confusing.  I'll hopefully try to help and explain below.

> I first cloned the repository:
>
> $ git clone https://github.com/CodeForChicago/superclass.git
>
> Then, I created a new branch (or so I thought):
>
> $ git checkout -b lesson_page

At this point, you created a *local* branch called 'lesson_page' which
points to the current HEAD and then switched to that branch .  This
local branch is independent of the remote branch called
'origin/lesson_page'.

> However, this branch has already existed for about 4 weeks, without my
> knowledge.  I proceeded to do some work on the files it contained, and when
> it came time to commit and push, and when I pushed, I got the following
> message:
>
> To https://github.com/CodeForChicago/superclass.git
>  ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
> error: failed to push some refs to '
> https://github.com/CodeForChicago/superclass.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
> Given that I had believed that I had created the branch just a few hours
> prior and was the first to attempt to push to it, this error was
> consternating.

The non-fast-forward push is preventing history being rewritten- this
is a good thing :).

> I may be wrong (I am aware that my understanding of git is limited), but I
> believe that the git checkout -b command is simply supposed to create a new
> branch and then switch to it (I'm not aware of any subtle behavior that goes
> on behind the scenes if the "new" branch that the user is attempting to
> create already exists).  This is why I said it "may not be a bug per se".
> However, I expect most people who use git to expect this command to create a
> new branch and then switch to it (this is what most sources online will tell
> users to do to create a new branch), and as such, it would be extremely
> beneficial if git were to, at the very least, alert the user to the conflict
> in some way or another.

The `git checkout -b` command is working as expected.  `git checkout
-b <name>` is equivalent to `git branch <name> && git checkout
<name>`.  If you were to execute `git checkout lesson_page`, you would
get the desired behavior you were expecting because in the presence of
one remote, git will actually execute `git checkout -b lesson_page
--track origin/lesson_page` - more details can be found in `git help
checkout`.  Effectively, it checkouts 'origin/lesson_page' as a new
local branch named 'lesson_page'.

However, you indicated that you did not know there was a remote
branch already named 'lesson_page'.  After cloning the repository, you
can use `git branch -a` to see all remotes to determine which form of
`git checkout` to use.

> Thanks,
> Ben
>
> Lead Consultant, Northwestern University Information Technology
> Research Assistant, Center for Interdisciplinary Exploration and Research in
> Astrophysics at Northwestern University
> Phsyics, Weinberg College of Arts and Sciences
> Computer Science, Weinberg College of Arts and Sciences
> Classics, Weinberg College of Arts and Sciences
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug Report

[Jacob Keller]

Hi,

On Sat, Apr 2, 2016 at 5:25 PM, Benjamin Sandeen
<benjaminsandeen2016@u.northwestern.edu> wrote:
> Today, I managed to create a duplicate branch in a git repository.  While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.
>
> I first cloned the repository:
>
> $ git clone https://github.com/CodeForChicago/superclass.git
>
> Then, I created a new branch (or so I thought):
>
> $ git checkout -b lesson_page
>
> However, this branch has already existed for about 4 weeks, without my
> knowledge.  I proceeded to do some work on the files it contained, and when
> it came time to commit and push, and when I pushed, I got the following
> message:

The branch existed in the remote repository, but it doesn't exist
locally. You never fetched a copy into refs/remotes/origin since you
didn't say you were interested, and git will fully allow you to create
local branches with the same name as remote branches.

>
> To https://github.com/CodeForChicago/superclass.git
>  ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
> error: failed to push some refs to '
> https://github.com/CodeForChicago/superclass.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>

When you tried to push this branch, it will push into
refs/heads/lesson_page on the remote, which already exists. Since it
cannot perform a fast-forward update, as your local work isn't based
directly on the tip of the remote branch, you either need to merge,
rebase, or start from scratch.

> Given that I had believed that I had created the branch just a few hours
> prior and was the first to attempt to push to it, this error was
> consternating.

Let me try to explain. You created your own local branch, which
happened to share the same name as an already existing branch. Had you
know this you could have fetched and checked out that branch. You can
view all branches using "git branch -a" or "git ls-remote".

>
> I may be wrong (I am aware that my understanding of git is limited), but I
> believe that the git checkout -b command is simply supposed to create a new
> branch and then switch to it (I'm not aware of any subtle behavior that goes
> on behind the scenes if the "new" branch that the user is attempting to
> create already exists).  This is why I said it "may not be a bug per se".
> However, I expect most people who use git to expect this command to create a
> new branch and then switch to it (this is what most sources online will tell
> users to do to create a new branch), and as such, it would be extremely
> beneficial if git were to, at the very least, alert the user to the conflict
> in some way or another.

git checkout -b <branch_name> will create a new branch in your local
copy of the repository. Git is distributed. You can do "git checkout
--track <branch>" to attempt to create a local branch which tracks the
upstream branch, and then git status will provide useful information
about the relationship between your local work and the remote work.

It could maybe be improved to notice that a remote has a branch with
the same name. However, git can support multiple remotes, so
determining which remote to care about is difficult.

In your case you have a couple of options to fix it. I would suggest at least

"git branch --set-upstream-to=origin/<branch_name>" so that git status
will give you useful information about the branch relationship. Then
you can merge or rebase your work into the branch.

The issue is in understanding how git distributes branches, and how it
could handle this. I suspect improvements could be made so that it
will attempt to warn you when you create a branch that already exists.
However, often you do this *intending* to make it track the specific
branch so I am not sure how much good a warning would do. Just a
message wouldn't really hurt anything, however.

Thanks,
Jake

>
> Thanks,
> Ben
>

Bug Report

[Alex Newman]

Hello mailing list friends,

I am sorry if this is not the best place for this (where should I
report improvements for perf).

This command works when I have the correct permissions but if I don't
rather than getting "bad permissions" I get

posix4e@posix4e-P27GV2:~$ perf stat -e 'ext4:' -a
invalid or unsupported event: 'ext4:'
Run 'perf list' for a list of valid events

usage: perf stat [] []

-e, --event <event>   event selector. use 'perf list' to list available events

I'd be happy to help fix this but I am still getting my head around
the parse_events infrastructure.

-Alex

Re: Bug Report

[David Ahern]

On 5/11/15 10:57 AM, Alex Newman wrote:
> Hello mailing list friends,
>
> I am sorry if this is not the best place for this (where should I
> report improvements for perf).
>
> This command works when I have the correct permissions but if I don't
> rather than getting "bad permissions" I get
>
> posix4e@posix4e-P27GV2:~$ perf stat -e 'ext4:' -a

that's an invalid event list; it should never work. Did you mean -e 
'ext4:*'?

David

Re: Bug Report

[Alex Newman]

Ah sorry for the typo. David, that's correct. But you should be able
to replicate that the error message is not revealing.

On Mon, May 11, 2015 at 10:14 AM, David Ahern <dsahern@gmail.com> wrote:
> On 5/11/15 10:57 AM, Alex Newman wrote:
>>
>> Hello mailing list friends,
>>
>> I am sorry if this is not the best place for this (where should I
>> report improvements for perf).
>>
>> This command works when I have the correct permissions but if I don't
>> rather than getting "bad permissions" I get
>>
>> posix4e@posix4e-P27GV2:~$ perf stat -e 'ext4:' -a
>
>
> that's an invalid event list; it should never work. Did you mean -e
> 'ext4:*'?
>
> David

Re: Bug Report

[Arnaldo Carvalho de Melo]

Em Mon, May 11, 2015 at 10:56:39AM -0700, Alex Newman escreveu:
> Ah sorry for the typo. David, that's correct. But you should be able
> to replicate that the error message is not revealing.

It should be changed to emit better messages like was done for 'perf
trace':

[acme@zoo linux]$ trace usleep 1
Error:	No permissions to read /sys/kernel/debug/tracing/events/raw_syscalls/sys_(enter|exit)
Hint:	Try 'sudo mount -o remount,mode=755 /sys/kernel/debug'

[acme@zoo linux]$ sudo mount -o remount,mode=755 /sys/kernel/debug
[sudo] password for acme: 
[acme@zoo linux]$ trace usleep 1
     0.095 ( 0.002 ms): usleep/974 brk(                                                                  ) = 0x7f2dc04fd000
     0.112 ( 0.003 ms): usleep/974 mmap(len: 4096, prot: READ|WRITE, flags: PRIVATE|ANONYMOUS, fd: -1    ) = 0x7f2dbf39e000
     0.123 ( 0.006 ms): usleep/974 access(filename: 0x7f2dbf19c270, mode: R                              ) = -1 ENOENT No such file or directory
     0.137 ( 0.006 ms): usleep/974 open(filename: 0x7f2dbf19ab92, flags: CLOEXEC                         ) = 3
     0.141 ( 0.002 ms): usleep/974 fstat(fd: 3, statbuf: 0x7ffffabf0d60                                  ) = 0
     0.146 ( 0.004 ms): usleep/974 mmap(len: 98505, prot: READ, flags: PRIVATE, fd: 3                    ) = 0x7f2dbf385000
     0.148 ( 0.001 ms): usleep/974 close(fd: 3                                                           ) = 0
     0.164 ( 0.007 ms): usleep/974 open(filename: 0x7f2dbf39427a, flags: CLOEXEC                         ) = 3
     0.168 ( 0.002 ms): usleep/974 read(fd: 3, buf: 0x7ffffabf0ef0, count: 832                           ) = 832
     0.171 ( 0.001 ms): usleep/974 fstat(fd: 3, statbuf: 0x7ffffabf0d90                                  ) = 0
     0.179 ( 0.005 ms): usleep/974 mmap(len: 2147728, prot: EXEC|READ, flags: PRIVATE|DENYWRITE, fd: 3   ) = 0x7f2dbef71000
     0.188 ( 0.007 ms): usleep/974 mprotect(start: 0x7f2dbef7c000, len: 2097152                          ) = 0
     0.194 ( 0.005 ms): usleep/974 mmap(addr: 0x7f2dbf17c000, len: 8192, prot: READ|WRITE, flags: PRIVATE|DENYWRITE|FIXED, fd: 3, off: 45056) = 0x7f2dbf17c000
     0.205 ( 0.001 ms): usleep/974 close(fd: 3                                                           ) = 0
     0.220 ( 0.007 ms): usleep/974 open(filename: 0x7f2dbf39b33b, flags: CLOEXEC                         ) = 3
     0.223 ( 0.002 ms): usleep/974 read(fd: 3, buf: 0x7ffffabf0ec0, count: 832                           ) = 832
     0.230 ( 0.002 ms): usleep/974 fstat(fd: 3, statbuf: 0x7ffffabf0d60                                  ) = 0
     0.237 ( 0.006 ms): usleep/974 mmap(len: 3919744, prot: EXEC|READ, flags: PRIVATE|DENYWRITE, fd: 3   ) = 0x7f2dbebb4000
     0.247 ( 0.009 ms): usleep/974 mprotect(start: 0x7f2dbed67000, len: 2097152                          ) = 0
     0.255 ( 0.006 ms): usleep/974 mmap(addr: 0x7f2dbef67000, len: 24576, prot: READ|WRITE, flags: PRIVATE|DENYWRITE|FIXED, fd: 3, off: 1781760) = 0x7f2dbef67000
     0.273 ( 0.011 ms): usleep/974 mmap(addr: 0x7f2dbef6d000, len: 16256, prot: READ|WRITE, flags: PRIVATE|ANONYMOUS|FIXED, fd: -1) = 0x7f2dbef6d000
     0.281 ( 0.001 ms): usleep/974 close(fd: 3                                                           ) = 0
     0.291 ( 0.003 ms): usleep/974 mmap(len: 4096, prot: READ|WRITE, flags: PRIVATE|ANONYMOUS, fd: -1    ) = 0x7f2dbf384000
     0.306 ( 0.003 ms): usleep/974 mmap(len: 4096, prot: READ|WRITE, flags: PRIVATE|ANONYMOUS, fd: -1    ) = 0x7f2dbf383000
     0.311 ( 0.002 ms): usleep/974 mmap(len: 4096, prot: READ|WRITE, flags: PRIVATE|ANONYMOUS, fd: -1    ) = 0x7f2dbf382000
     0.316 ( 0.001 ms): usleep/974 arch_prctl(option: 4098, arg2: 139834458388224, arg3: 139834458382352, arg4: 34, arg5: 4294967295) = 0
     0.386 ( 0.006 ms): usleep/974 mprotect(start: 0x7f2dbef67000, len: 16384, prot: READ                ) = 0
     0.396 ( 0.003 ms): usleep/974 mprotect(start: 0x7f2dbf17c000, len: 4096, prot: READ                 ) = 0
     0.407 ( 0.004 ms): usleep/974 mprotect(start: 0x7f2dbf5a3000, len: 4096, prot: READ                 ) = 0
     0.416 ( 0.005 ms): usleep/974 mprotect(start: 0x7f2dbf39f000, len: 4096, prot: READ                 ) = 0
     0.429 ( 0.012 ms): usleep/974 munmap(addr: 0x7f2dbf385000, len: 98505                               ) = 0
     0.487 ( 0.002 ms): usleep/974 brk(                                                                  ) = 0x7f2dc04fd000
     0.492 ( 0.004 ms): usleep/974 brk(brk: 0x7f2dc051e000                                               ) = 0x7f2dc051e000
     0.495 ( 0.001 ms): usleep/974 brk(                                                                  ) = 0x7f2dc051e000
     0.573 ( 0.059 ms): usleep/974 nanosleep(rqtp: 0x7ffffabf14e0                                        ) = 0
     0.581 ( 0.000 ms): usleep/974 exit_group(                                                           
[acme@zoo linux]$ 

[acme@zoo linux]$ trace --all-cpus
Error:	Operation not permitted.
Hint:	Check /proc/sys/kernel/perf_event_paranoid setting.
Hint:	For system wide tracing it needs to be set to -1.
Hint:	Try: 'sudo sh -c "echo -1 > /proc/sys/kernel/perf_event_paranoid"'
Hint:	The current value is 1.
[acme@zoo linux]$ 

Will try to do it soon,

- Arnaldo
 
> On Mon, May 11, 2015 at 10:14 AM, David Ahern <dsahern@gmail.com> wrote:
> > On 5/11/15 10:57 AM, Alex Newman wrote:
> >>
> >> Hello mailing list friends,
> >>
> >> I am sorry if this is not the best place for this (where should I
> >> report improvements for perf).
> >>
> >> This command works when I have the correct permissions but if I don't
> >> rather than getting "bad permissions" I get
> >>
> >> posix4e@posix4e-P27GV2:~$ perf stat -e 'ext4:' -a
> >
> >
> > that's an invalid event list; it should never work. Did you mean -e
> > 'ext4:*'?
> >
> > David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug report

[Albert Akhriev]

Hi All,

My system:                      RedHat 6.5/64-bit (gcc 4.4.7)
My configuration options:  ./configure --prefix=/home/albert/soft

Compilation of git 2.2.2 itself was fine, but some tests failed.
I presume, there might be some network communication restrictions here in
the lab
(gitweb had failed as can be seen in the listing below):

1..14
*** t9400-git-cvsserver-server.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9401-git-cvsserver-crlf.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9402-git-cvsserver-refs.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9500-gitweb-standalone-no-errors.sh ***
not ok 1 - no commits: projects_list (implicit)
#	gitweb_run
not ok 2 - no commits: projects_index
#	gitweb_run "a=project_index"
not ok 3 - no commits: .git summary (implicit)
#	gitweb_run "p=.git"
not ok 4 - no commits: .git commit (implicit HEAD)
#	gitweb_run "p=.git;a=commit"
not ok 5 - no commits: .git commitdiff (implicit HEAD)
#	gitweb_run "p=.git;a=commitdiff"
not ok 6 - no commits: .git tree (implicit HEAD)
#	gitweb_run "p=.git;a=tree"
not ok 7 - no commits: .git heads
#	gitweb_run "p=.git;a=heads"
not ok 8 - no commits: .git tags
#	gitweb_run "p=.git;a=tags"
ok 9 - Make initial commit
not ok 10 - projects_list (implicit)
#	gitweb_run
not ok 11 - projects_index
#	gitweb_run "a=project_index"
not ok 12 - .git summary (implicit)
#	gitweb_run "p=.git"
not ok 13 - .git commit (implicit HEAD)
#	gitweb_run "p=.git;a=commit"
not ok 14 - .git commitdiff (implicit HEAD, root commit)
#	gitweb_run "p=.git;a=commitdiff"
not ok 15 - .git commitdiff_plain (implicit HEAD, root commit)
#	gitweb_run "p=.git;a=commitdiff_plain"
not ok 16 - .git commit (HEAD)
#	gitweb_run "p=.git;a=commit;h=HEAD"
not ok 17 - .git tree (implicit HEAD)
#	gitweb_run "p=.git;a=tree"
not ok 18 - .git blob (file)
#	gitweb_run "p=.git;a=blob;f=file"
not ok 19 - .git blob_plain (file)
#	gitweb_run "p=.git;a=blob_plain;f=file"
not ok 20 - .git commit (non-existent)
#	gitweb_run "p=.git;a=commit;h=non-existent"
not ok 21 - .git commitdiff (non-existent)
#	gitweb_run "p=.git;a=commitdiff;h=non-existent"
not ok 22 - .git commitdiff (non-existent vs HEAD)
#	gitweb_run "p=.git;a=commitdiff;hp=non-existent;h=HEAD"
not ok 23 - .git tree (0000000000000000000000000000000000000000)
#	gitweb_run "p=.git;a=tree;h=0000000000000000000000000000000000000000"
not ok 24 - .git tag (0000000000000000000000000000000000000000)
#	gitweb_run "p=.git;a=tag;h=0000000000000000000000000000000000000000"
not ok 25 - .git blob (non-existent)
#	gitweb_run "p=.git;a=blob;f=non-existent"
not ok 26 - .git blob_plain (non-existent)
#	gitweb_run "p=.git;a=blob_plain;f=non-existent"
not ok 27 - commitdiff(0): root
#	gitweb_run "p=.git;a=commitdiff"
not ok 28 - commitdiff(0): file added
#	echo "New file" > new_file &&
#		 git add new_file &&
#		 git commit -a -m "File added." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 29 - commitdiff(0): mode change
#	test_chmod +x new_file &&
#		 git commit -a -m "Mode changed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 30 - commitdiff(0): file renamed
#	git mv new_file renamed_file &&
#		 git commit -a -m "File renamed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 31 - commitdiff(0): file to symlink
#	rm renamed_file &&
#		 test_ln_s_add file renamed_file &&
#		 git commit -a -m "File to symlink." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 32 - commitdiff(0): file deleted
#	git rm renamed_file &&
#		 rm -f renamed_file &&
#		 git commit -a -m "File removed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 33 - commitdiff(0): file copied / new file
#	cp file file2 &&
#		 git add file2 &&
#		 git commit -a -m "File copied." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 34 - commitdiff(0): mode change and modified
#	echo "New line" >> file2 &&
#		 test_chmod +x file2 &&
#		 git commit -a -m "Mode change and modification." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 35 - commitdiff(0): renamed and modified
#	cat >file2<<EOF &&
#	Dominus regit me,
#	et nihil mihi deerit.
#	In loco pascuae ibi me collocavit,
#	super aquam refectionis educavit me;
#	animam meam convertit,
#	deduxit me super semitas jusitiae,
#	propter nomen suum.
#	EOF
#		 git commit -a -m "File added." &&
#		 git mv file2 file3 &&
#		 echo "Propter nomen suum." >> file3 &&
#		 git commit -a -m "File rename and modification." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 36 - commitdiff(0): renamed, mode change and modified
#	git mv file3 file2 &&
#		 echo "Propter nomen suum." >> file2 &&
#		 test_chmod +x file2 &&
#		 git commit -a -m "File rename, mode change and modification."
&&
#		 gitweb_run "p=.git;a=commitdiff"
ok 37 - setup typechange commits
not ok 38 - commitdiff(2): file renamed from foo to foo/baz
#	gitweb_run
"p=.git;a=commitdiff;hp=initial;h=foo-baz-renamed-from-foo"
not ok 39 - commitdiff(2): file renamed from foo/baz to foo
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-baz-renamed-from-foo;h=initial"
not ok 40 - commitdiff(2): directory becomes file
#	gitweb_run "p=.git;a=commitdiff;hp=foo-becomes-a-directory;h=initial"
not ok 41 - commitdiff(2): file becomes directory
#	gitweb_run "p=.git;a=commitdiff;hp=initial;h=foo-becomes-a-directory"
not ok 42 - commitdiff(2): file becomes symlink
#	gitweb_run "p=.git;a=commitdiff;hp=initial;h=foo-symlinked-to-bar"
not ok 43 - commitdiff(2): symlink becomes file
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-symlinked-to-bar;h=foo-back-to-file"
not ok 44 - commitdiff(2): symlink becomes directory
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-symlinked-to-bar;h=foo-becomes-a-directory"
not ok 45 - commitdiff(2): directory becomes symlink
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-becomes-a-directory;h=foo-symlinked-to-bar"
ok 46 - setup incomplete lines
not ok 47 - commitdiff(1): addition of incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_add"
#
not ok 48 - commitdiff(1): incomplete line as context line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_ctx"
#
not ok 49 - commitdiff(1): change incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_chg"
#
not ok 50 - commitdiff(1): removal of incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_rem"
#
ok 51 - Create a merge
not ok 52 - commit(0): merge commit
#	gitweb_run "p=.git;a=commit"
not ok 53 - commitdiff(0): merge commit
#	gitweb_run "p=.git;a=commitdiff"
ok 54 - Prepare large commit
not ok 55 - commit(1): large commit
#	gitweb_run "p=.git;a=commit;h=b"
not ok 56 - commitdiff(1): large commit
#	gitweb_run "p=.git;a=commitdiff;h=b"
not ok 57 - side-by-side: addition of incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_add;ds=sidebyside"
#
not ok 58 - side-by-side: incomplete line as context line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_ctx;ds=sidebyside"
#
not ok 59 - side-by-side: changed incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_chg;ds=sidebyside"
#
not ok 60 - side-by-side: removal of incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_rem;ds=sidebyside"
#
not ok 61 - side-by-side: merge commit
#
#		gitweb_run "p=.git;a=commitdiff;h=merge_commit;ds=sidebyside"
#
not ok 62 - tags: list of different types of tags
#	git checkout master &&
#		 git tag -a -m "Tag commit object" tag-commit HEAD &&
#		 git tag -a -m "" tag-commit-nomessage HEAD &&
#		 git tag -a -m "Tag tag object" tag-tag tag-commit &&
#		 git tag -a -m "Tag tree object" tag-tree HEAD^{tree} &&
#		 git tag -a -m "Tag blob object" tag-blob HEAD:file &&
#		 git tag lightweight/tag-commit HEAD &&
#		 git tag lightweight/tag-tag tag-commit &&
#		 git tag lightweight/tag-tree HEAD^{tree} &&
#		 git tag lightweight/tag-blob HEAD:file &&
#		 gitweb_run "p=.git;a=tags"
not ok 63 - tag: Tag to commit object
#	gitweb_run "p=.git;a=tag;h=tag-commit"
not ok 64 - tag: on lightweight tag (invalid)
#	gitweb_run "p=.git;a=tag;h=lightweight/tag-commit"
not ok 65 - logs: log (implicit HEAD)
#	gitweb_run "p=.git;a=log"
not ok 66 - logs: shortlog (implicit HEAD)
#	gitweb_run "p=.git;a=shortlog"
not ok 67 - logs: history (implicit HEAD, file)
#	gitweb_run "p=.git;a=history;f=file"
not ok 68 - logs: history (implicit HEAD, non-existent file)
#	gitweb_run "p=.git;a=history;f=non-existent"
not ok 69 - logs: history (implicit HEAD, deleted file)
#	git checkout master &&
#		 echo "to be deleted" > deleted_file &&
#		 git add deleted_file &&
#		 git commit -m "Add file to be deleted" &&
#		 git rm deleted_file &&
#		 git commit -m "Delete file" &&
#		 gitweb_run "p=.git;a=history;f=deleted_file"
not ok 70 - path_info: project
#	gitweb_run "" "/.git"
not ok 71 - path_info: project/branch
#	gitweb_run "" "/.git/b"
not ok 72 - path_info: project/branch:file
#	gitweb_run "" "/.git/master:file"
not ok 73 - path_info: project/branch:dir/
#	gitweb_run "" "/.git/master:foo/"
not ok 74 - path_info: project/branch (non-existent)
#	gitweb_run "" "/.git/non-existent"
not ok 75 - path_info: project/branch:filename (non-existent branch)
#	gitweb_run "" "/.git/non-existent:non-existent"
not ok 76 - path_info: project/branch:file (non-existent)
#	gitweb_run "" "/.git/master:non-existent"
not ok 77 - path_info: project/branch:dir/ (non-existent)
#	gitweb_run "" "/.git/master:non-existent/"
not ok 78 - path_info: project/branch:/file
#	gitweb_run "" "/.git/master:/file"
not ok 79 - path_info: project/:/file (implicit HEAD)
#	gitweb_run "" "/.git/:/file"
not ok 80 - path_info: project/:/ (implicit HEAD, top tree)
#	gitweb_run "" "/.git/:/"
not ok 81 - feeds: OPML
#	gitweb_run "a=opml"
not ok 82 - feed: RSS
#	gitweb_run "p=.git;a=rss"
not ok 83 - feed: Atom
#	gitweb_run "p=.git;a=atom"
not ok 84 - encode(commit): utf8
#	. "$TEST_DIRECTORY"/t3901-utf8.txt &&
#		 test_when_finished "GIT_AUTHOR_NAME=\"A U Thor\"" &&
#		 test_when_finished "GIT_COMMITTER_NAME=\"C O Mitter\"" &&
#		 echo "UTF-8" >> file &&
#		 git add file &&
#		 git commit -F "$TEST_DIRECTORY"/t3900/1-UTF-8.txt &&
#		 gitweb_run "p=.git;a=commit"
not ok 85 - encode(commit): iso-8859-1
#	. "$TEST_DIRECTORY"/t3901-8859-1.txt &&
#		 test_when_finished "GIT_AUTHOR_NAME=\"A U Thor\"" &&
#		 test_when_finished "GIT_COMMITTER_NAME=\"C O Mitter\"" &&
#		 echo "ISO-8859-1" >> file &&
#		 git add file &&
#		 test_config i18n.commitencoding ISO-8859-1 &&
#		 git commit -F "$TEST_DIRECTORY"/t3900/ISO8859-1.txt &&
#		 gitweb_run "p=.git;a=commit"
not ok 86 - encode(log): utf-8 and iso-8859-1
#	gitweb_run "p=.git;a=log"
not ok 87 - opt: log --no-merges
#	gitweb_run "p=.git;a=log;opt=--no-merges"
not ok 88 - opt: atom --no-merges
#	gitweb_run "p=.git;a=log;opt=--no-merges"
not ok 89 - opt: "file" history --no-merges
#	gitweb_run "p=.git;a=history;f=file;opt=--no-merges"
not ok 90 - opt: log --no-such-option (invalid option)
#	gitweb_run "p=.git;a=log;opt=--no-such-option"
not ok 91 - opt: tree --no-merges (invalid option for action)
#	gitweb_run "p=.git;a=tree;opt=--no-merges"
not ok 92 - URL: no project URLs, no base URL
#	gitweb_run "p=.git;a=summary"
not ok 93 - URL: project URLs via gitweb.url
#	git config --add gitweb.url git://example.com/git/trash.git &&
#	        git config --add gitweb.url http://example.com/git/trash.git
&&
#	        gitweb_run "p=.git;a=summary"
not ok 94 - URL: project URLs via cloneurl file
#	gitweb_run "p=.git;a=summary"
not ok 95 - config override: projects list (implicit)
#	gitweb_run
not ok 96 - config override: tree view, features not overridden in repo
config
#	gitweb_run "p=.git;a=tree"
not ok 97 - config override: tree view, features disabled in repo config
#	git config gitweb.blame no &&
#		 git config gitweb.snapshot none &&
#		 git config gitweb.avatar gravatar &&
#		 gitweb_run "p=.git;a=tree"
not ok 98 - config override: tree view, features enabled in repo config (1)
#	git config gitweb.blame yes &&
#		 git config gitweb.snapshot "zip,tgz, tbz2" &&
#		 gitweb_run "p=.git;a=tree"
not ok 99 - config override: tree view, features enabled in repo config (2)
#	gitweb_run "p=.git;a=tree"
ok 100 - search: preparation
not ok 101 - search: commit author
#	gitweb_run "p=.git;a=search;h=HEAD;st=author;s=A+U+Thor"
not ok 102 - search: commit message
#	gitweb_run "p=.git;a=search;h=HEAD;st=commitr;s=MATCH"
not ok 103 - search: grep
#	gitweb_run "p=.git;a=search;h=HEAD;st=grep;s=MATCH"
not ok 104 - search: pickaxe
#	gitweb_run "p=.git;a=search;h=HEAD;st=pickaxe;s=MATCH"
not ok 105 - search: projects
#	gitweb_run "a=project_list;s=.git"
not ok 106 - README.html with non-ASCII characters (utf-8)
#	echo "<b>UTF-8 example:</b><br />" > .git/README.html &&
#		 cat "$TEST_DIRECTORY"/t3900/1-UTF-8.txt >> .git/README.html &&
#		 gitweb_run "p=.git;a=summary"
Skipping syntax highlighting tests: 'highlight' not found
ok 107 # skip syntax highlighting (no highlight, unknown syntax) (missing
HIGHLIGHT)
ok 108 # skip syntax highlighting (highlighted, shell script) (missing
HIGHLIGHT)
ok 109 - forks: prepare
not ok 110 - forks: projects list
#	gitweb_run
not ok 111 - forks: forks action
#	gitweb_run "p=foo.git;a=forks"
not ok 112 - ctags: tag cloud in projects list
#	mkdir .git/ctags &&
#		 echo "2" > .git/ctags/foo &&
#		 echo "1" > .git/ctags/bar &&
#		gitweb_run
not ok 113 - ctags: search projects by existing tag
#	gitweb_run "by_tag=foo"
not ok 114 - ctags: search projects by non existent tag
#	gitweb_run "by_tag=non-existent"
not ok 115 - ctags: malformed tag weights
#	mkdir -p .git/ctags &&
#		 echo "not-a-number" > .git/ctags/nan &&
#		 echo "not-a-number-2" > .git/ctags/nan2 &&
#		 echo "0.1" >.git/ctags/floating-point &&
#		 gitweb_run
not ok 116 - categories: projects list, only default category
#	echo "\$projects_list_group_categories = 1;" >>gitweb_config.perl &&
#		 gitweb_run
not ok 117 - unborn HEAD: "summary" page (with "heads" subview)
#	git checkout orphan_branch || git checkout --orphan orphan_branch &&
#		 test_when_finished "git checkout master" &&
#		 gitweb_run "p=.git;a=summary"
# failed 108 among 117 test(s)
1..117
make[2]: *** [t9500-gitweb-standalone-no-errors.sh] Error 1
make[2]: Leaving directory
`/home/albert/work/info/install_ver2/git-2.2.2/t'
make[1]: *** [test] Error 2
make[1]: Leaving directory
`/home/albert/work/info/install_ver2/git-2.2.2/t'
make: *** [test] Error 2

Best regards,

Albert Akhriev, PhD
IBM Research - Ireland
Tech. Campus, Bldg 3,  | Mulhuddart, Dublin 15
http://researcher.ibm.com/person/ie-albert_akhriev
albert_akhriev@ie.ibm.com | +353 1 826 91 86

IBM Ireland Limited registered in Ireland under company number 16226.
Registered Office: IBM House, Shelbourne Rd., Ballsbridge, Dublin 4.

Re: bug report

[Jeff King]

On Tue, Jan 27, 2015 at 02:43:31PM +0000, Albert Akhriev wrote:

> My system:                      RedHat 6.5/64-bit (gcc 4.4.7)
> My configuration options:  ./configure --prefix=/home/albert/soft
> 
> Compilation of git 2.2.2 itself was fine, but some tests failed.
> I presume, there might be some network communication restrictions here in
> the lab
> (gitweb had failed as can be seen in the listing below):

The gitweb tests should run locally and not need to touch the network.
It looks like gitweb cannot run at all. Are you sure you have a working
perl (with CGI and other base modules)?

Try running:

  cd t
  ./t9500-gitweb-standaloneno-errors.sh -v -i

which should give more output. Also check the contents of gitweb.log in
"t/trash directory/t9500-...".

-Peff

bug report

[Zhu, Zhengyun]

Hi,

When I am using fio to do some tests, I find a problem.

I am using a client with a 10Gb NIC to do the test case of sequential read, and the configuration file is below:

//version 2.0.8
global]
iodepth=256
runtime=600
ioengine=libaio
direct=1
size=30g
filename=/dev/vdb
ramp_time=10

[seq-read-64k]
rw=read
bs=64k
iodepth_batch_submit=8
iodepth_batch_complete=8


we know the bandwidth can reach nearly 1100MB/s without the parameter of rate. It will finish fio in about 30 seconds, because the size is 30g.

first, when I set ramp_time to 10, the fio result is below:

seq-read-64k: (groupid=0, jobs=1): err= 0: pid=26840
� read : io=20016MB, bw=1105.8MB/s, iops=17677 , runt= 18102msec

second, when I set ramp_time to 35, the fio result is below:

seq-read-64k: (groupid=0, jobs=1): err= 0: pid=26861
� read : io=30720MB, bw=1102.3MB/s, iops=17636 , runt= 27870msec

According to these, we can summary:

1. When we set ramp_time less than the time of fio finish read(we call it fftime for short), then
���� Runt = fftime - ramptime
2. When we set ramp_time greater than the time of fio finish read(we call it fftime for short), then
� Runt = fftime
My requirement is:
� I want to use ramp time to warm up 50 seconds, and then collect iostat data, but fio has finished after 30 seconds, so I will collect all empty data.

Could we not calculate time and io size during ramp time in runt time, or do I have some mistakes to understand it?

Re: bug report

[Vasily Tarasov]

Hi Zhu,

If the total run time of the job is only 30 seconds, there is no way
to have a warm-up time more than 30 seconds. In fact, during the
warm-up time fio executes exactly same workload as during the "main"
run. That is a definition of warm-up time. So, if the whole workload
can run for only 30 seconds, there is no way to warm the system up for
more than 30 seconds with this workload.

I think you need to make your experiment longer. For example, you can
use "loops=" parameter to execute a job multiple times.

HTH,
Vasily

On Tue, Aug 5, 2014 at 1:08 AM, Zhu, Zhengyun <zhengyun.zhu@intel.com> wrote:
>
> Hi,
>
> When I am using fio to do some tests, I find a problem.
>
> I am using a client with a 10Gb NIC to do the test case of sequential read, and the configuration file is below:
>
> //version 2.0.8
> global]
> iodepth=256
> runtime=600
> ioengine=libaio
> direct=1
> size=30g
> filename=/dev/vdb
> ramp_time=10
>
> [seq-read-64k]
> rw=read
> bs=64k
> iodepth_batch_submit=8
> iodepth_batch_complete=8
>
>
> we know the bandwidth can reach nearly 1100MB/s without the parameter of rate. It will finish fio in about 30 seconds, because the size is 30g.
>
> first, when I set ramp_time to 10, the fio result is below:
>
> seq-read-64k: (groupid=0, jobs=1): err= 0: pid=26840
>   read : io=20016MB, bw=1105.8MB/s, iops=17677 , runt= 18102msec
>
> second, when I set ramp_time to 35, the fio result is below:
>
> seq-read-64k: (groupid=0, jobs=1): err= 0: pid=26861
>   read : io=30720MB, bw=1102.3MB/s, iops=17636 , runt= 27870msec
>
> According to these, we can summary:
>
> 1. When we set ramp_time less than the time of fio finish read(we call it fftime for short), then
>      Runt = fftime - ramptime
> 2. When we set ramp_time greater than the time of fio finish read(we call it fftime for short), then
>   Runt = fftime
> My requirement is:
>   I want to use ramp time to warm up 50 seconds, and then collect iostat data, but fio has finished after 30 seconds, so I will collect all empty data.
>
> Could we not calculate time and io size during ramp time in runt time, or do I have some mistakes to understand it?
> --
> To unsubscribe from this list: send the line "unsubscribe fio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Bug Report

[Rajiv Shah]

Hi,
I am reporting a bug on behalf of William Schaub at the Ubuntu Launchpad 
Bug Tracker. The link below directs you to the report and a patch.
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1173904

Thank you,
Rajiv Shah
Triager
Ubuntu Launchpad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20130524/37049cd3/attachment.htm>

Bug Report

[Bryn M. Reeves]

On 05/24/2013 11:32 PM, Rajiv Shah wrote:
> I am reporting a bug on behalf of William Schaub at the Ubuntu Launchpad
> Bug Tracker. The link below directs you to the report and a patch.
> https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1173904

The patch attached to the launchpad ticket modifies debian/rules and 
debian/dmeventd.install to enable internal mirrors and add the correct 
dmeventd files.

The debian directory is not included in upstream lvm2 so this needs to 
be changed in the Ubuntu packaging.

There's another hunk changing tools/Makefile.in but it just shuffles 
some LVMLIBS/LIBS command line arguments around - it doesn't look like 
it actually fixes anything.

Regards,
Bryn.

Bug Report

[Kirk Fraser]

It appears your Amazon download server is too slow.  Perhaps getting
an old used XP system and setting it up as a server will solve this
problem.

Here's the details:


PLATFORM VERSION INFO
	Windows 			: 6.1.7601.65536 (Win32NT)
	Common Language Runtime 	: 4.0.30319.296
	System.Deployment.dll 		: 4.0.30319.1 (RTMRel.030319-0100)
	clr.dll 			: 4.0.30319.296 (RTMGDR.030319-2900)
	dfdll.dll 			: 4.0.30319.1 (RTMRel.030319-0100)

SOURCES
	Deployment url			: http://github-windows.s3.amazonaws.com/GitHub.application
						Server		: AmazonS3
	Application url			:
http://github-windows.s3.amazonaws.com/Application%20Files/GitHub_1_0_41_2/GitHub.exe.manifest
						Server		: AmazonS3

IDENTITIES
	Deployment Identity		: GitHub.application, Version=1.0.41.2,
Culture=neutral, PublicKeyToken=317444273a93ac29,
processorArchitecture=x86
	Application Identity		: GitHub.exe, Version=1.0.41.2,
Culture=neutral, PublicKeyToken=317444273a93ac29,
processorArchitecture=x86, type=win32

APPLICATION SUMMARY
	* Installable application.
	* Trust url parameter is set.
ERROR SUMMARY
	Below is a summary of the errors, details of these errors are listed
later in the log.
	* Activation of
http://github-windows.s3.amazonaws.com/GitHub.application resulted in
exception. Following failure messages were detected:
		+ Downloading http://github-windows.s3.amazonaws.com/Application
Files/GitHub_1_0_41_2/7za.exe.deploy did not succeed.
		+ Unable to read data from the transport connection: An existing
connection was forcibly closed by the remote host.
		+ An existing connection was forcibly closed by the remote host

COMPONENT STORE TRANSACTION FAILURE SUMMARY
	No transaction error was detected.

WARNINGS
	There were no warnings during this operation.

OPERATION PROGRESS STATUS
	* [4/7/2013 9:17:17 PM] : Activation of
http://github-windows.s3.amazonaws.com/GitHub.application has started.
	* [4/7/2013 9:17:30 PM] : Processing of deployment manifest has
successfully completed.
	* [4/7/2013 9:17:30 PM] : Installation of the application has started.
	* [4/7/2013 9:17:34 PM] : Processing of application manifest has
successfully completed.
	* [4/7/2013 9:23:57 PM] : Found compatible runtime version 4.0.30319.
	* [4/7/2013 9:23:57 PM] : Request of trust and detection of platform
is complete.

ERROR DETAILS
	Following errors were detected during this operation.
	* [4/7/2013 9:51:39 PM]
System.Deployment.Application.DeploymentDownloadException (Unknown
subtype)
		- Downloading http://github-windows.s3.amazonaws.com/Application
Files/GitHub_1_0_41_2/7za.exe.deploy did not succeed.
		- Source: System.Deployment
		- Stack trace:
			at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem
next)
			at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
			at System.Deployment.Application.FileDownloader.Download(SubscriptionState
subState)
			at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState
subState, AssemblyManifest deployManifest, AssemblyManifest
appManifest, Uri sourceUriBase, String targetDirectory, String group,
IDownloadNotification notification, DownloadOptions options)
			at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState
subState, ActivationDescription actDesc, Int64 transactionId,
TempDirectory& downloadTemp)
			at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState&
subState, ActivationDescription actDesc)
			at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri
activationUri, Boolean isShortcut, String textualSubId, String
deploymentProviderUrlFromExtension, BrowserSettings browserSettings,
String& errorPageUrl)
			at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object
state)
		--- Inner Exception ---
		System.IO.IOException
		- Unable to read data from the transport connection: An existing
connection was forcibly closed by the remote host.
		- Source: System
		- Stack trace:
			at System.Net.ConnectStream.Read(Byte[] buffer, Int32 offset, Int32 size)
			at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem
next)
		--- Inner Exception ---
		System.Net.Sockets.SocketException
		- An existing connection was forcibly closed by the remote host
		- Source: System
		- Stack trace:
			at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset,
Int32 size, SocketFlags socketFlags)
			at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32
offset, Int32 size)

COMPONENT STORE TRANSACTION DETAILS
	No transaction information is available.



-- 
Kirk W. Fraser
http://freetom.info/TrueChurch - Replace the fraud churches with the
true church.
http://congressionalbiblestudy.org - Fix America by first fixing its
Christian foundation.
http://freetom.info - Example of False Justice common in America

Bug Report

[Roberto CORRADO]

[-- Attachment #1.1: Type: text/plain, Size: 46670 bytes --]

Mar  3 06:32:18 hp530 kernel: [20049.642823] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!
Mar  3 06:32:18 hp530 kernel: [20049.642836] ------------[ cut here ]------------
Mar  3 06:32:18 hp530 kernel: [20049.642877] WARNING: at drivers/gpu/drm/i915/intel_display.c:7877 intel_modeset_check_state+0x4b0/0x620 [i915]()
Mar  3 06:32:18 hp530 kernel: [20049.642882] Hardware name: HP 530 Notebook PC
Mar  3 06:32:18 hp530 kernel: [20049.642888] encoder's hw state doesn't match sw tracking (expected 1, found 0)
Mar  3 06:32:18 hp530 kernel: [20049.642892] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse i2c_dev hid_generic usbhid hid i915 drm_kms_helper coretemp e100 drm acpi_cpufreq mperf snd_hda_codec_conexant lpc_ich joydev freq_table video processor snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc i2c_algo_bit i2c_core snd_timer thermal fan snd mii uhci_hcd hp_wmi thermal_sys sparse_keymap psmouse serio_raw wmi yenta_socket pcmcia_rsrc hwmon soundcore intel_agp intel_gtt agpgart evdev microcode ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  3 06:32:18 hp530 kernel: [20049.643076] Pid: 29238, comm: kworker/0:1 Not tainted 3.8.2-hp530.corradoroberto.it #1
Mar  3 06:32:18 hp530 kernel: [20049.643081] Call Trace:
Mar  3 06:32:18 hp530 kernel: [20049.643098]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  3 06:32:18 hp530 kernel: [20049.643129]  [<f8b2da40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643158]  [<f8b2da40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643168]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  3 06:32:18 hp530 kernel: [20049.643198]  [<f8b2da40>] intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643222]  [<f8870900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  3 06:32:18 hp530 kernel: [20049.643251]  [<f8b2e398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643288]  [<f8b30bdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643320]  [<f8b32d9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643330]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  3 06:32:18 hp530 kernel: [20049.643343]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  3 06:32:18 hp530 kernel: [20049.643352]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  3 06:32:18 hp530 kernel: [20049.643364]  [<f89811d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  3 06:32:18 hp530 kernel: [20049.643377]  [<f89815ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  3 06:32:18 hp530 kernel: [20049.643389]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  3 06:32:18 hp530 kernel: [20049.643398]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  3 06:32:18 hp530 kernel: [20049.643407]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  3 06:32:18 hp530 kernel: [20049.643417]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  3 06:32:18 hp530 kernel: [20049.643429]  [<c14cddb3>] ? common_interrupt+0x33/0x38
Mar  3 06:32:18 hp530 kernel: [20049.643439]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  3 06:32:18 hp530 kernel: [20049.643448]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  3 06:32:18 hp530 kernel: [20049.643458]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  3 06:32:18 hp530 kernel: [20049.643467]  [<c10585f4>] kthread+0x94/0xa0
Mar  3 06:32:18 hp530 kernel: [20049.643478]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  3 06:32:18 hp530 kernel: [20049.643486]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  3 06:32:18 hp530 kernel: [20049.643493] ---[ end trace 2b519babbf9a2c65 ]---

Mar  3 06:32:18 hp530 kernel: [20049.643501] ------------[ cut here ]------------
Mar  3 06:32:18 hp530 kernel: [20049.643530] WARNING: at drivers/gpu/drm/i915/intel_display.c:7911 intel_modeset_check_state+0x481/0x620 [i915]()
Mar  3 06:32:18 hp530 kernel: [20049.643535] Hardware name: HP 530 Notebook PC
Mar  3 06:32:18 hp530 kernel: [20049.643540] crtc's computed active state doesn't match tracked active state (expected 1, found 0)
Mar  3 06:32:18 hp530 kernel: [20049.643544] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse i2c_dev hid_generic usbhid hid i915 drm_kms_helper coretemp e100 drm acpi_cpufreq mperf snd_hda_codec_conexant lpc_ich joydev freq_table video processor snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc i2c_algo_bit i2c_core snd_timer thermal fan snd mii uhci_hcd hp_wmi thermal_sys sparse_keymap psmouse serio_raw wmi yenta_socket pcmcia_rsrc hwmon soundcore intel_agp intel_gtt agpgart evdev microcode ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  3 06:32:18 hp530 kernel: [20049.643663] Pid: 29238, comm: kworker/0:1 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  3 06:32:18 hp530 kernel: [20049.643668] Call Trace:
Mar  3 06:32:18 hp530 kernel: [20049.643678]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  3 06:32:18 hp530 kernel: [20049.643708]  [<f8b2da11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643737]  [<f8b2da11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643746]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  3 06:32:18 hp530 kernel: [20049.643776]  [<f8b2da11>] intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643798]  [<f8870900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  3 06:32:18 hp530 kernel: [20049.643828]  [<f8b2e398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643864]  [<f8b30bdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643896]  [<f8b32d9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  3 06:32:18 hp530 kernel: [20049.643905]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  3 06:32:18 hp530 kernel: [20049.643917]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  3 06:32:18 hp530 kernel: [20049.643926]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  3 06:32:18 hp530 kernel: [20049.643938]  [<f89811d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  3 06:32:18 hp530 kernel: [20049.643950]  [<f89815ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  3 06:32:18 hp530 kernel: [20049.643961]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  3 06:32:18 hp530 kernel: [20049.643969]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  3 06:32:18 hp530 kernel: [20049.643978]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  3 06:32:18 hp530 kernel: [20049.643987]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  3 06:32:18 hp530 kernel: [20049.643997]  [<c14cddb3>] ? common_interrupt+0x33/0x38
Mar  3 06:32:18 hp530 kernel: [20049.644024]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  3 06:32:18 hp530 kernel: [20049.644034]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  3 06:32:18 hp530 kernel: [20049.644044]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  3 06:32:18 hp530 kernel: [20049.644052]  [<c10585f4>] kthread+0x94/0xa0
Mar  3 06:32:18 hp530 kernel: [20049.644063]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  3 06:32:18 hp530 kernel: [20049.644071]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  3 06:32:18 hp530 kernel: [20049.644078] ---[ end trace 2b519babbf9a2c66 ]---


Mar  3 09:44:53 hp530 udevd[1158]: could not find module by name='rtc_cmos' 
Mar  3 12:41:50 hp530 kernel: [10634.976059] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!
Mar  3 12:41:50 hp530 kernel: [10634.976074] ------------[ cut here ]------------
Mar  3 12:41:50 hp530 kernel: [10634.976114] WARNING: at drivers/gpu/drm/i915/intel_display.c:7877 intel_modeset_check_state+0x4b0/0x620 [i915]()
Mar  3 12:41:50 hp530 kernel: [10634.976120] Hardware name: HP 530 Notebook PC
Mar  3 12:41:50 hp530 kernel: [10634.976125] encoder's hw state doesn't match sw tracking (expected 1, found 0)
Mar  3 12:41:50 hp530 kernel: [10634.976130] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  3 12:41:50 hp530 kernel: [10634.976263] Pid: 3778, comm: kworker/0:1 Not tainted 3.8.2-hp530.corradoroberto.it #1
Mar  3 12:41:50 hp530 kernel: [10634.976268] Call Trace:
Mar  3 12:41:50 hp530 kernel: [10634.976284]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  3 12:41:50 hp530 kernel: [10634.976315]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976344]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976354]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  3 12:41:50 hp530 kernel: [10634.976384]  [<f87faa40>] intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976408]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  3 12:41:50 hp530 kernel: [10634.976438]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976474]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976507]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976517]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  3 12:41:50 hp530 kernel: [10634.976530]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  3 12:41:50 hp530 kernel: [10634.976538]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  3 12:41:50 hp530 kernel: [10634.976551]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  3 12:41:50 hp530 kernel: [10634.976564]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  3 12:41:50 hp530 kernel: [10634.976576]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  3 12:41:50 hp530 kernel: [10634.976585]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  3 12:41:50 hp530 kernel: [10634.976594]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  3 12:41:50 hp530 kernel: [10634.976604]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  3 12:41:50 hp530 kernel: [10634.976614]  [<c10483a6>] ? mod_timer+0xf6/0x1b0
Mar  3 12:41:50 hp530 kernel: [10634.976623]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  3 12:41:50 hp530 kernel: [10634.976633]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  3 12:41:50 hp530 kernel: [10634.976643]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  3 12:41:50 hp530 kernel: [10634.976651]  [<c10585f4>] kthread+0x94/0xa0
Mar  3 12:41:50 hp530 kernel: [10634.976664]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  3 12:41:50 hp530 kernel: [10634.976673]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  3 12:41:50 hp530 kernel: [10634.976679] ---[ end trace 2cee81eec134a13e ]---

Mar  3 12:41:50 hp530 kernel: [10634.976687] ------------[ cut here ]------------
Mar  3 12:41:50 hp530 kernel: [10634.976716] WARNING: at drivers/gpu/drm/i915/intel_display.c:7911 intel_modeset_check_state+0x481/0x620 [i915]()
Mar  3 12:41:50 hp530 kernel: [10634.976720] Hardware name: HP 530 Notebook PC
Mar  3 12:41:50 hp530 kernel: [10634.976725] crtc's computed active state doesn't match tracked active state (expected 1, found 0)
Mar  3 12:41:50 hp530 kernel: [10634.976730] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  3 12:41:50 hp530 kernel: [10634.976849] Pid: 3778, comm: kworker/0:1 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  3 12:41:50 hp530 kernel: [10634.976854] Call Trace:
Mar  3 12:41:50 hp530 kernel: [10634.976864]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  3 12:41:50 hp530 kernel: [10634.976894]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976923]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976932]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  3 12:41:50 hp530 kernel: [10634.976962]  [<f87faa11>] intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.976984]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  3 12:41:50 hp530 kernel: [10634.977009]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.977075]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.977134]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  3 12:41:50 hp530 kernel: [10634.977169]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  3 12:41:50 hp530 kernel: [10634.977210]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  3 12:41:50 hp530 kernel: [10634.977247]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  3 12:41:50 hp530 kernel: [10634.977281]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  3 12:41:50 hp530 kernel: [10634.977294]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  3 12:41:50 hp530 kernel: [10634.977304]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  3 12:41:50 hp530 kernel: [10634.977312]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  3 12:41:50 hp530 kernel: [10634.977321]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  3 12:41:50 hp530 kernel: [10634.977330]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  3 12:41:50 hp530 kernel: [10634.977340]  [<c10483a6>] ? mod_timer+0xf6/0x1b0
Mar  3 12:41:50 hp530 kernel: [10634.977349]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  3 12:41:50 hp530 kernel: [10634.977358]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  3 12:41:50 hp530 kernel: [10634.977368]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  3 12:41:50 hp530 kernel: [10634.977376]  [<c10585f4>] kthread+0x94/0xa0
Mar  3 12:41:50 hp530 kernel: [10634.977387]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  3 12:41:50 hp530 kernel: [10634.977396]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  3 12:41:50 hp530 kernel: [10634.977402] ---[ end trace 2cee81eec134a13f ]---

Mar  3 13:31:43 hp530 kernel: [13628.212949] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!
Mar  3 13:31:43 hp530 kernel: [13628.212958] ------------[ cut here ]------------
Mar  3 13:31:43 hp530 kernel: [13628.212984] WARNING: at drivers/gpu/drm/i915/intel_display.c:7877 intel_modeset_check_state+0x4b0/0x620 [i915]()
Mar  3 13:31:43 hp530 kernel: [13628.212987] Hardware name: HP 530 Notebook PC
Mar  3 13:31:43 hp530 kernel: [13628.212990] encoder's hw state doesn't match sw tracking (expected 1, found 0)
Mar  3 13:31:43 hp530 kernel: [13628.212992] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  3 13:31:43 hp530 kernel: [13628.213094] Pid: 3936, comm: kworker/0:0 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  3 13:31:43 hp530 kernel: [13628.213097] Call Trace:
Mar  3 13:31:43 hp530 kernel: [13628.213107]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  3 13:31:43 hp530 kernel: [13628.213121]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213135]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213139]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  3 13:31:43 hp530 kernel: [13628.213153]  [<f87faa40>] intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213179]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  3 13:31:43 hp530 kernel: [13628.213196]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213212]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213227]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213232]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  3 13:31:43 hp530 kernel: [13628.213239]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  3 13:31:43 hp530 kernel: [13628.213243]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  3 13:31:43 hp530 kernel: [13628.213249]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  3 13:31:43 hp530 kernel: [13628.213255]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  3 13:31:43 hp530 kernel: [13628.213262]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  3 13:31:43 hp530 kernel: [13628.213266]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  3 13:31:43 hp530 kernel: [13628.213271]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  3 13:31:43 hp530 kernel: [13628.213276]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  3 13:31:43 hp530 kernel: [13628.213283]  [<c14cd388>] ? apic_timer_interrupt+0x34/0x3c
Mar  3 13:31:43 hp530 kernel: [13628.213287]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  3 13:31:43 hp530 kernel: [13628.213292]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  3 13:31:43 hp530 kernel: [13628.213296]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  3 13:31:43 hp530 kernel: [13628.213301]  [<c10585f4>] kthread+0x94/0xa0
Mar  3 13:31:43 hp530 kernel: [13628.213306]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  3 13:31:43 hp530 kernel: [13628.213310]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  3 13:31:43 hp530 kernel: [13628.213313] ---[ end trace 2cee81eec134a140 ]---

Mar  3 13:31:43 hp530 kernel: [13628.213318] ------------[ cut here ]------------
Mar  3 13:31:43 hp530 kernel: [13628.213331] WARNING: at drivers/gpu/drm/i915/intel_display.c:7911 intel_modeset_check_state+0x481/0x620 [i915]()
Mar  3 13:31:43 hp530 kernel: [13628.213333] Hardware name: HP 530 Notebook PC
Mar  3 13:31:43 hp530 kernel: [13628.213336] crtc's computed active state doesn't match tracked active state (expected 1, found 0)
Mar  3 13:31:43 hp530 kernel: [13628.213337] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  3 13:31:43 hp530 kernel: [13628.213393] Pid: 3936, comm: kworker/0:0 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  3 13:31:43 hp530 kernel: [13628.213395] Call Trace:
Mar  3 13:31:43 hp530 kernel: [13628.213399]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  3 13:31:43 hp530 kernel: [13628.213413]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213427]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213431]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  3 13:31:43 hp530 kernel: [13628.213445]  [<f87faa11>] intel_modeset_check_state+0x481/0x620 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213455]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  3 13:31:43 hp530 kernel: [13628.213469]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213485]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213500]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  3 13:31:43 hp530 kernel: [13628.213504]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  3 13:31:43 hp530 kernel: [13628.213510]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  3 13:31:43 hp530 kernel: [13628.213514]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  3 13:31:43 hp530 kernel: [13628.213520]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  3 13:31:43 hp530 kernel: [13628.213525]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  3 13:31:43 hp530 kernel: [13628.213530]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  3 13:31:43 hp530 kernel: [13628.213534]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  3 13:31:43 hp530 kernel: [13628.213538]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  3 13:31:43 hp530 kernel: [13628.213542]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  3 13:31:43 hp530 kernel: [13628.213547]  [<c14cd388>] ? apic_timer_interrupt+0x34/0x3c
Mar  3 13:31:43 hp530 kernel: [13628.213551]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  3 13:31:43 hp530 kernel: [13628.213556]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  3 13:31:43 hp530 kernel: [13628.213560]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  3 13:31:43 hp530 kernel: [13628.213564]  [<c10585f4>] kthread+0x94/0xa0
Mar  3 13:31:43 hp530 kernel: [13628.213569]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  3 13:31:43 hp530 kernel: [13628.213573]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  3 13:31:43 hp530 kernel: [13628.213575] ---[ end trace 2cee81eec134a141 ]---

Mar  4 01:18:06 hp530 kernel: [56011.447750] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!
Mar  4 01:18:06 hp530 kernel: [56011.447763] ------------[ cut here ]------------
Mar  4 01:18:06 hp530 kernel: [56011.447804] WARNING: at drivers/gpu/drm/i915/intel_display.c:7877 intel_modeset_check_state+0x4b0/0x620 [i915]()
Mar  4 01:18:06 hp530 kernel: [56011.447809] Hardware name: HP 530 Notebook PC
Mar  4 01:18:06 hp530 kernel: [56011.447814] encoder's hw state doesn't match sw tracking (expected 1, found 0)
Mar  4 01:18:06 hp530 kernel: [56011.447819] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  4 01:18:06 hp530 kernel: [56011.447954] Pid: 17834, comm: kworker/0:2 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  4 01:18:06 hp530 kernel: [56011.447960] Call Trace:
Mar  4 01:18:06 hp530 kernel: [56011.447976]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  4 01:18:06 hp530 kernel: [56011.448007]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448064]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448102]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  4 01:18:06 hp530 kernel: [56011.448151]  [<f87faa40>] intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448175]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  4 01:18:06 hp530 kernel: [56011.448205]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448242]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448274]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448284]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  4 01:18:06 hp530 kernel: [56011.448297]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  4 01:18:06 hp530 kernel: [56011.448306]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  4 01:18:06 hp530 kernel: [56011.448318]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  4 01:18:06 hp530 kernel: [56011.448331]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  4 01:18:06 hp530 kernel: [56011.448343]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  4 01:18:06 hp530 kernel: [56011.448352]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  4 01:18:06 hp530 kernel: [56011.448362]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  4 01:18:06 hp530 kernel: [56011.448372]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  4 01:18:06 hp530 kernel: [56011.448382]  [<c10483a6>] ? mod_timer+0xf6/0x1b0
Mar  4 01:18:06 hp530 kernel: [56011.448392]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  4 01:18:06 hp530 kernel: [56011.448401]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  4 01:18:06 hp530 kernel: [56011.448411]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  4 01:18:06 hp530 kernel: [56011.448420]  [<c10585f4>] kthread+0x94/0xa0
Mar  4 01:18:06 hp530 kernel: [56011.448433]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  4 01:18:06 hp530 kernel: [56011.448442]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  4 01:18:06 hp530 kernel: [56011.448448] ---[ end trace 2cee81eec134a142 ]---

Mar  4 01:18:06 hp530 kernel: [56011.448456] ------------[ cut here ]------------
Mar  4 01:18:06 hp530 kernel: [56011.448485] WARNING: at drivers/gpu/drm/i915/intel_display.c:7911 intel_modeset_check_state+0x481/0x620 [i915]()
Mar  4 01:18:06 hp530 kernel: [56011.448490] Hardware name: HP 530 Notebook PC
Mar  4 01:18:06 hp530 kernel: [56011.448495] crtc's computed active state doesn't match tracked active state (expected 1, found 0)
Mar  4 01:18:06 hp530 kernel: [56011.448499] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  4 01:18:06 hp530 kernel: [56011.448618] Pid: 17834, comm: kworker/0:2 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  4 01:18:06 hp530 kernel: [56011.448623] Call Trace:
Mar  4 01:18:06 hp530 kernel: [56011.448633]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  4 01:18:06 hp530 kernel: [56011.448664]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448692]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448702]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  4 01:18:06 hp530 kernel: [56011.448731]  [<f87faa11>] intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448754]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  4 01:18:06 hp530 kernel: [56011.448783]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448820]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448852]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  4 01:18:06 hp530 kernel: [56011.448861]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  4 01:18:06 hp530 kernel: [56011.448873]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  4 01:18:06 hp530 kernel: [56011.448882]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  4 01:18:06 hp530 kernel: [56011.448894]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  4 01:18:06 hp530 kernel: [56011.448906]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  4 01:18:06 hp530 kernel: [56011.448916]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  4 01:18:06 hp530 kernel: [56011.448925]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  4 01:18:06 hp530 kernel: [56011.448933]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  4 01:18:06 hp530 kernel: [56011.448943]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  4 01:18:06 hp530 kernel: [56011.448952]  [<c10483a6>] ? mod_timer+0xf6/0x1b0
Mar  4 01:18:06 hp530 kernel: [56011.448961]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  4 01:18:06 hp530 kernel: [56011.448971]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  4 01:18:06 hp530 kernel: [56011.448980]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  4 01:18:06 hp530 kernel: [56011.448988]  [<c10585f4>] kthread+0x94/0xa0
Mar  4 01:18:06 hp530 kernel: [56011.448999]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  4 01:18:06 hp530 kernel: [56011.449024]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  4 01:18:06 hp530 kernel: [56011.449030] ---[ end trace 2cee81eec134a143 ]---

Mar  4 02:13:44 hp530 kernel: [59349.423573] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!

Mar  4 02:13:44 hp530 kernel: [59349.423587] ------------[ cut here ]------------
Mar  4 02:13:44 hp530 kernel: [59349.423628] WARNING: at drivers/gpu/drm/i915/intel_display.c:7877 intel_modeset_check_state+0x4b0/0x620 [i915]()
Mar  4 02:13:44 hp530 kernel: [59349.423634] Hardware name: HP 530 Notebook PC
Mar  4 02:13:44 hp530 kernel: [59349.423639] encoder's hw state doesn't match sw tracking (expected 1, found 0)
Mar  4 02:13:44 hp530 kernel: [59349.423644] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  4 02:13:44 hp530 kernel: [59349.423779] Pid: 19662, comm: kworker/0:2 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  4 02:13:44 hp530 kernel: [59349.423785] Call Trace:
Mar  4 02:13:44 hp530 kernel: [59349.423801]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  4 02:13:44 hp530 kernel: [59349.423832]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.423861]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.423871]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  4 02:13:44 hp530 kernel: [59349.423901]  [<f87faa40>] intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.423925]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  4 02:13:44 hp530 kernel: [59349.423955]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.423992]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424051]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424090]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  4 02:13:44 hp530 kernel: [59349.424124]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  4 02:13:44 hp530 kernel: [59349.424150]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  4 02:13:44 hp530 kernel: [59349.424163]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  4 02:13:44 hp530 kernel: [59349.424176]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  4 02:13:44 hp530 kernel: [59349.424188]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  4 02:13:44 hp530 kernel: [59349.424197]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  4 02:13:44 hp530 kernel: [59349.424207]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  4 02:13:44 hp530 kernel: [59349.424217]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  4 02:13:44 hp530 kernel: [59349.424229]  [<c14cd388>] ? apic_timer_interrupt+0x34/0x3c
Mar  4 02:13:44 hp530 kernel: [59349.424239]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  4 02:13:44 hp530 kernel: [59349.424249]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  4 02:13:44 hp530 kernel: [59349.424258]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  4 02:13:44 hp530 kernel: [59349.424267]  [<c10585f4>] kthread+0x94/0xa0
Mar  4 02:13:44 hp530 kernel: [59349.424278]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  4 02:13:44 hp530 kernel: [59349.424286]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  4 02:13:44 hp530 kernel: [59349.424293] ---[ end trace 2cee81eec134a144 ]---

Mar  4 02:13:44 hp530 kernel: [59349.424301] ------------[ cut here ]------------
Mar  4 02:13:44 hp530 kernel: [59349.424330] WARNING: at drivers/gpu/drm/i915/intel_display.c:7911 intel_modeset_check_state+0x481/0x620 [i915]()
Mar  4 02:13:44 hp530 kernel: [59349.424335] Hardware name: HP 530 Notebook PC
Mar  4 02:13:44 hp530 kernel: [59349.424340] crtc's computed active state doesn't match tracked active state (expected 1, found 0)
Mar  4 02:13:44 hp530 kernel: [59349.424344] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  4 02:13:44 hp530 kernel: [59349.424464] Pid: 19662, comm: kworker/0:2 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  4 02:13:44 hp530 kernel: [59349.424469] Call Trace:
Mar  4 02:13:44 hp530 kernel: [59349.424479]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  4 02:13:44 hp530 kernel: [59349.424509]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424538]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424548]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  4 02:13:44 hp530 kernel: [59349.424577]  [<f87faa11>] intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424600]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  4 02:13:44 hp530 kernel: [59349.424630]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424666]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424698]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  4 02:13:44 hp530 kernel: [59349.424708]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  4 02:13:44 hp530 kernel: [59349.424719]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  4 02:13:44 hp530 kernel: [59349.424728]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  4 02:13:44 hp530 kernel: [59349.424741]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  4 02:13:44 hp530 kernel: [59349.424753]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  4 02:13:44 hp530 kernel: [59349.424763]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  4 02:13:44 hp530 kernel: [59349.424771]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  4 02:13:44 hp530 kernel: [59349.424780]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  4 02:13:44 hp530 kernel: [59349.424789]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  4 02:13:44 hp530 kernel: [59349.424799]  [<c14cd388>] ? apic_timer_interrupt+0x34/0x3c
Mar  4 02:13:44 hp530 kernel: [59349.424809]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  4 02:13:44 hp530 kernel: [59349.424818]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  4 02:13:44 hp530 kernel: [59349.424828]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  4 02:13:44 hp530 kernel: [59349.424836]  [<c10585f4>] kthread+0x94/0xa0
Mar  4 02:13:44 hp530 kernel: [59349.424846]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  4 02:13:44 hp530 kernel: [59349.424855]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  4 02:13:44 hp530 kernel: [59349.424861] ---[ end trace 2cee81eec134a145 ]---
Mar  4 05:34:19 hp530 kernel: [71383.915780] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!

Mar  4 05:34:19 hp530 kernel: [71383.915794] ------------[ cut here ]------------
Mar  4 05:34:19 hp530 kernel: [71383.915835] WARNING: at drivers/gpu/drm/i915/intel_display.c:7877 intel_modeset_check_state+0x4b0/0x620 [i915]()
Mar  4 05:34:19 hp530 kernel: [71383.915840] Hardware name: HP 530 Notebook PC
Mar  4 05:34:19 hp530 kernel: [71383.915846] encoder's hw state doesn't match sw tracking (expected 1, found 0)
Mar  4 05:34:19 hp530 kernel: [71383.915850] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  4 05:34:19 hp530 kernel: [71383.915986] Pid: 20368, comm: kworker/0:1 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  4 05:34:19 hp530 kernel: [71383.915991] Call Trace:
Mar  4 05:34:19 hp530 kernel: [71383.916008]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  4 05:34:19 hp530 kernel: [71383.916066]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916123]  [<f87faa40>] ? intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916150]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  4 05:34:19 hp530 kernel: [71383.916180]  [<f87faa40>] intel_modeset_check_state+0x4b0/0x620 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916204]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  4 05:34:19 hp530 kernel: [71383.916234]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916271]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916304]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916314]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  4 05:34:19 hp530 kernel: [71383.916327]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  4 05:34:19 hp530 kernel: [71383.916336]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  4 05:34:19 hp530 kernel: [71383.916348]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  4 05:34:19 hp530 kernel: [71383.916361]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  4 05:34:19 hp530 kernel: [71383.916373]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  4 05:34:19 hp530 kernel: [71383.916382]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  4 05:34:19 hp530 kernel: [71383.916391]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  4 05:34:19 hp530 kernel: [71383.916401]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  4 05:34:19 hp530 kernel: [71383.916411]  [<c1050ca0>] ? need_to_create_worker+0x10/0x30
Mar  4 05:34:19 hp530 kernel: [71383.916420]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  4 05:34:19 hp530 kernel: [71383.916429]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  4 05:34:19 hp530 kernel: [71383.916439]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  4 05:34:19 hp530 kernel: [71383.916448]  [<c10585f4>] kthread+0x94/0xa0
Mar  4 05:34:19 hp530 kernel: [71383.916461]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  4 05:34:19 hp530 kernel: [71383.916469]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  4 05:34:19 hp530 kernel: [71383.916476] ---[ end trace 2cee81eec134a146 ]---

Mar  4 05:34:19 hp530 kernel: [71383.916483] ------------[ cut here ]------------
Mar  4 05:34:19 hp530 kernel: [71383.916512] WARNING: at drivers/gpu/drm/i915/intel_display.c:7911 intel_modeset_check_state+0x481/0x620 [i915]()
Mar  4 05:34:19 hp530 kernel: [71383.916517] Hardware name: HP 530 Notebook PC
Mar  4 05:34:19 hp530 kernel: [71383.916522] crtc's computed active state doesn't match tracked active state (expected 1, found 0)
Mar  4 05:34:19 hp530 kernel: [71383.916526] Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cpufreq_ondemand speedstep_lib fuse hid_generic usbhid hid i2c_dev lpc_ich coretemp i915 drm_kms_helper drm hp_wmi sparse_keymap i2c_algo_bit i2c_core acpi_cpufreq e100 joydev mperf uhci_hcd freq_table mii thermal psmouse yenta_socket pcmcia_rsrc wmi video processor fan thermal_sys hwmon serio_raw snd_hda_codec_conexant evdev intel_agp intel_gtt agpgart microcode snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore ehci_pci ehci_hcd battery container button ac loop b43 mac80211 cfg80211 rfkill ssb mmc_core pcmcia pcmcia_core reiserfs
Mar  4 05:34:19 hp530 kernel: [71383.916646] Pid: 20368, comm: kworker/0:1 Tainted: G        W    3.8.2-hp530.corradoroberto.it #1
Mar  4 05:34:19 hp530 kernel: [71383.916651] Call Trace:
Mar  4 05:34:19 hp530 kernel: [71383.916661]  [<c1038ea2>] warn_slowpath_common+0x72/0xa0
Mar  4 05:34:19 hp530 kernel: [71383.916691]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916720]  [<f87faa11>] ? intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916729]  [<c1038f73>] warn_slowpath_fmt+0x33/0x40
Mar  4 05:34:19 hp530 kernel: [71383.916759]  [<f87faa11>] intel_modeset_check_state+0x481/0x620 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916781]  [<f8656900>] ? drm_property_destroy+0x20/0xa0 [drm]
Mar  4 05:34:19 hp530 kernel: [71383.916811]  [<f87fb398>] intel_set_mode+0x788/0x9d0 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916847]  [<f87fdbdd>] intel_modeset_setup_hw_state+0x54d/0x8f0 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916879]  [<f87ffd9b>] intel_lid_notify+0x9b/0xc0 [i915]
Mar  4 05:34:19 hp530 kernel: [71383.916889]  [<c105e603>] notifier_call_chain+0x43/0x60
Mar  4 05:34:19 hp530 kernel: [71383.916900]  [<c105e841>] __blocking_notifier_call_chain+0x41/0x80
Mar  4 05:34:19 hp530 kernel: [71383.916909]  [<c105e89f>] blocking_notifier_call_chain+0x1f/0x30
Mar  4 05:34:19 hp530 kernel: [71383.916921]  [<f89751d0>] acpi_lid_send_state+0x78/0xa4 [button]
Mar  4 05:34:19 hp530 kernel: [71383.916934]  [<f89755ea>] acpi_button_notify+0x3b/0xb6 [button]
Mar  4 05:34:19 hp530 kernel: [71383.916944]  [<c127c91a>] acpi_device_notify+0x16/0x18
Mar  4 05:34:19 hp530 kernel: [71383.916952]  [<c1289157>] acpi_ev_notify_dispatch+0x33/0x4a
Mar  4 05:34:19 hp530 kernel: [71383.916961]  [<c127944c>] acpi_os_execute_deferred+0x20/0x2b
Mar  4 05:34:19 hp530 kernel: [71383.916971]  [<c1051ea0>] process_one_work+0x120/0x3e0
Mar  4 05:34:19 hp530 kernel: [71383.916980]  [<c1050ca0>] ? need_to_create_worker+0x10/0x30
Mar  4 05:34:19 hp530 kernel: [71383.916989]  [<c127942c>] ? acpi_os_wait_events_complete+0x1e/0x1e
Mar  4 05:34:19 hp530 kernel: [71383.916998]  [<c1053de9>] worker_thread+0x119/0x3a0
Mar  4 05:34:19 hp530 kernel: [71383.917023]  [<c1053cd0>] ? busy_worker_rebind_fn+0xd0/0xd0
Mar  4 05:34:19 hp530 kernel: [71383.917032]  [<c10585f4>] kthread+0x94/0xa0
Mar  4 05:34:19 hp530 kernel: [71383.917043]  [<c14cd7f7>] ret_from_kernel_thread+0x1b/0x28
Mar  4 05:34:19 hp530 kernel: [71383.917051]  [<c1058560>] ? kthread_create_on_node+0xc0/0xc0
Mar  4 05:34:19 hp530 kernel: [71383.917057] ---[ end trace 2cee81eec134a147 ]---

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6097 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Bug report

[Муковников Михаил]

There's a problem using git with files having cyrillic 'й' in their name, git just can't track them.

uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
git version: 1.7.12.1 (from macports)

Steps to reproduce:
- git init
- touch test_й
- git status (should be "untracked files present")
- git add test_й
- git status

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	"test_\320\270\314\206"
nothing added to commit but untracked files present (use "git add" to track)

Could this be helped somehow?

Re: Bug report

[Konstantin Khomoutov]

On Fri, 5 Oct 2012 14:13:49 +0400
Муковников Михаил <m.mukovnikov@gmail.com> wrote:

> There's a problem using git with files having cyrillic 'й' in their
> name, git just can't track them.
> 
> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
> version: 1.7.12.1 (from macports)
> 
> Steps to reproduce:
> - git init
> - touch test_й
> - git status (should be "untracked files present")
> - git add test_й
> - git status
> 
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #	"test_\320\270\314\206"
> nothing added to commit but untracked files present (use "git add" to
> track)
> 
> Could this be helped somehow?--

What "this"?  If you mean displaying escapes for UTF-8 bytes
representing that letter "й", then try setting core.quotepath to false
for this repository and see if that helps.

More info can be found in the git-config manual page.

Re: Bug report

[Carlos Martín Nieto]

Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:

> On Fri, 5 Oct 2012 14:13:49 +0400
> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
>
>> There's a problem using git with files having cyrillic 'й' in their
>> name, git just can't track them.
>> 
>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>> version: 1.7.12.1 (from macports)
>> 
>> Steps to reproduce:
>> - git init
>> - touch test_й
>> - git status (should be "untracked files present")
>> - git add test_й
>> - git status
>> 
>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #	"test_\320\270\314\206"
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>> 
>> Could this be helped somehow?--
>
> What "this"?  If you mean displaying escapes for UTF-8 bytes
> representing that letter "й", then try setting core.quotepath to false
> for this repository and see if that helps.

Notice the 'git add test_й'. The problem is that git reports it as untracked.

Михаил, is this the whole output or do you also see a
differently-escaped version of the filename under tracked files? Does
this problem not show up if you use 'git add -A' or 'git add .' instead
of typing the name? If so, this happens because HFS+ stores and reports
names differently than the way we told it to store it, so git sees a
different set of bytes than what it's expecting and considers it a
different file.

With a recent version of git, you can set the core.precomposeunicode
config setting to true, which deals with this situation. This tells git
to transform the data it gets from the filesystem to the format that
everyone else uses, which helps not only this, but also the 'git add .'
case, so git stores the filename in the format the same way that other
OSs expect to find.

   cmn

Re: Bug report

[Муковников Михаил]

Carlos, thank you very much, core.precomposeunicode works just like you said.
And you're right, it seems the problem is in HFS+, 'git add .' worked as well, so did even 'git add test_*'.
The problem seems solved.

05.10.2012, в 14:47, cmn@elego.de (Carlos Martín Nieto) написал(а):

> Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:
> 
>> On Fri, 5 Oct 2012 14:13:49 +0400
>> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
>> 
>>> There's a problem using git with files having cyrillic 'й' in their
>>> name, git just can't track them.
>>> 
>>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>>> version: 1.7.12.1 (from macports)
>>> 
>>> Steps to reproduce:
>>> - git init
>>> - touch test_й
>>> - git status (should be "untracked files present")
>>> - git add test_й
>>> - git status
>>> 
>>> # Untracked files:
>>> #   (use "git add <file>..." to include in what will be committed)
>>> #
>>> #	"test_\320\270\314\206"
>>> nothing added to commit but untracked files present (use "git add" to
>>> track)
>>> 
>>> Could this be helped somehow?--
>> 
>> What "this"?  If you mean displaying escapes for UTF-8 bytes
>> representing that letter "й", then try setting core.quotepath to false
>> for this repository and see if that helps.
> 
> Notice the 'git add test_й'. The problem is that git reports it as untracked.
> 
> Михаил, is this the whole output or do you also see a
> differently-escaped version of the filename under tracked files? Does
> this problem not show up if you use 'git add -A' or 'git add .' instead
> of typing the name? If so, this happens because HFS+ stores and reports
> names differently than the way we told it to store it, so git sees a
> different set of bytes than what it's expecting and considers it a
> different file.
> 
> With a recent version of git, you can set the core.precomposeunicode
> config setting to true, which deals with this situation. This tells git
> to transform the data it gets from the filesystem to the format that
> everyone else uses, which helps not only this, but also the 'git add .'
> case, so git stores the filename in the format the same way that other
> OSs expect to find.
> 
>   cmn

Re: Bug report

[Муковников Михаил]

Hey, Konstantin!
Thanks for your reply. My bad, I described the problem not very well. I don't mind displaying escapes etc. (core.quotepath just makes "\320\270\314\206" be "й" and that's it), the problem is that git cannot track files with cyrillic "й" in their name. I created a file, added it but git writes it's still untracked, and it seems there's no way to track it.

05.10.2012, в 14:32, Konstantin Khomoutov <flatworm@users.sourceforge.net> написал(а):

> On Fri, 5 Oct 2012 14:13:49 +0400
> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
> 
>> There's a problem using git with files having cyrillic 'й' in their
>> name, git just can't track them.
>> 
>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>> version: 1.7.12.1 (from macports)
>> 
>> Steps to reproduce:
>> - git init
>> - touch test_й
>> - git status (should be "untracked files present")
>> - git add test_й
>> - git status
>> 
>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #	"test_\320\270\314\206"
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>> 
>> Could this be helped somehow?--
> 
> What "this"?  If you mean displaying escapes for UTF-8 bytes
> representing that letter "й", then try setting core.quotepath to false
> for this repository and see if that helps.
> 
> More info can be found in the git-config manual page.

Bug report

[John Whitney]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

Hi all!

I just ran into a problem that I'm pretty sure is a bug in git. Just 
read and run this (fairly trivial) shell script to replicate.

Thanks!
    ---John Whitney


[-- Attachment #2: git_failure.sh --]
[-- Type: application/x-sh, Size: 1186 bytes --]

Re: Bug report

[Phil Hord]

On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <jjw@emsoftware.com> wrote:
> I just ran into a problem that I'm pretty sure is a bug in git. Just read
> and run this (fairly trivial) shell script to replicate.

When you added "* text=auto" in the .gitattributes file, you changed
what git considers to be the checked-in file content state for
test.txt.  The file contents in your working directory do not match
what git expects to check in.  Therefore, the file appears to be
different.  If you commit the file "changes" the problem goes away.

This is more of a workaround than an a satisfying explanation.  If you
then checkout the original HEAD commit (but with .gitattributes
present) you will see the problem appear again.  But in a sense,
adding .gitattributes this way is an act of foot-shooting.   The best
way forward may be to normalize your repository by removing all CR's
from files in history.  If you do not have this freedom, your best bet
may be to normalize the repo in the current commit and move on.

Others with more intimate insight into the CRLF journey in git's past
may have better advice.

Phil

Re: Bug report

[John Whitney]

Phil,

Thank you for your response. I do see the dilemma, but having
no possible "unmodified" state is extremely inconvenient and,
as shown, breaks basic git operations.

I guess my thought is that if git doesn't allow CRs to be checked
in, then it should strip the CRs when checking the file out, and
consider that form (or both forms) as "unmodified". It just
doesn't make sense to me that files are considered modified
immediately after checkout.

Any thoughts as to why this would not work?

    ---John

On 10/4/12 9:19 AM, Phil Hord wrote:
> On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <jjw@emsoftware.com> wrote:
>> I just ran into a problem that I'm pretty sure is a bug in git. Just read
>> and run this (fairly trivial) shell script to replicate.
> When you added "* text=auto" in the .gitattributes file, you changed
> what git considers to be the checked-in file content state for
> test.txt.  The file contents in your working directory do not match
> what git expects to check in.  Therefore, the file appears to be
> different.  If you commit the file "changes" the problem goes away.
>
> This is more of a workaround than an a satisfying explanation.  If you
> then checkout the original HEAD commit (but with .gitattributes
> present) you will see the problem appear again.  But in a sense,
> adding .gitattributes this way is an act of foot-shooting.   The best
> way forward may be to normalize your repository by removing all CR's
> from files in history.  If you do not have this freedom, your best bet
> may be to normalize the repo in the current commit and move on.
>
> Others with more intimate insight into the CRLF journey in git's past
> may have better advice.
>
> Phil
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

Re: Bug report

[Jeff King]

On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:

> Thank you for your response. I do see the dilemma, but having
> no possible "unmodified" state is extremely inconvenient and,
> as shown, breaks basic git operations.

But you have asked for an impossible state. You have said "this file
cannot have CR when you check it in, because we erase them". And yet the
version of the file in HEAD has CRs in it. So it must appear modified
with respect to HEAD.  And the solution is to make a commit with the
normalized content.

You said in your test script:

  # Committing test.txt or clearing .gitattributes does clear
  # the "modified" status, but those options are undesirable

Why is the commit undesirable? You have decided that CRs will no longer
be tolerated in your repository (by setting .gitattributes). Now you
need to record that change in history with a commit that strips out the
CRs.

> I guess my thought is that if git doesn't allow CRs to be checked
> in, then it should strip the CRs when checking the file out, and
> consider that form (or both forms) as "unmodified". It just
> doesn't make sense to me that files are considered modified
> immediately after checkout.

It is not about having CRs in the working tree file. Those are now
considered uninteresting and stripped by git when comparing to the HEAD.
The problem is that what's in your _repository_ has CRs.

I wonder if this is a fundamental misunderstanding of how the CRLF
handling in git works. It is not "magically make me not care about line
endings anymore". It is "the canonical version in the repo is LF-only.
Strip anything coming into the repository to match that, and
(optionally) add CR to anything going out to the filesystem for my
convenience". But you need a flag day to update the in-repository
versions to the new scheme.

-Peff

Re: Bug report

[John Whitney]

On 10/6/12 8:31 AM, Jeff King wrote:
> On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:
>
>> Thank you for your response. I do see the dilemma, but having
>> no possible "unmodified" state is extremely inconvenient and,
>> as shown, breaks basic git operations.
> But you have asked for an impossible state. You have said "this file
> cannot have CR when you check it in, because we erase them". And yet the
> version of the file in HEAD has CRs in it. So it must appear modified
> with respect to HEAD.  And the solution is to make a commit with the
> normalized content.
I guess I'd really like to see git ignore all line endings of text files 
in the repository. Text files would then never be marked as "modified" 
for this reason and there would be no need to "fix" the line endings. I 
think that should be the default, but just having the option would be nice.

> You said in your test script:
>
>    # Committing test.txt or clearing .gitattributes does clear
>    # the "modified" status, but those options are undesirable
>
> Why is the commit undesirable? You have decided that CRs will no longer
> be tolerated in your repository (by setting .gitattributes). Now you
> need to record that change in history with a commit that strips out the
> CRs.
In some cases it's undesirable. In my example, all I want to do is merge 
in the change that deletes the file, so I don't want to have to add that 
extra commit when I'm just going to delete the file anyway. It's also 
very inconvenient to have to deal with this issue when you're in the 
middle of a complex rebase operation.

>> I guess my thought is that if git doesn't allow CRs to be checked
>> in, then it should strip the CRs when checking the file out, and
>> consider that form (or both forms) as "unmodified". It just
>> doesn't make sense to me that files are considered modified
>> immediately after checkout.
> It is not about having CRs in the working tree file. Those are now
> considered uninteresting and stripped by git when comparing to the HEAD.
> The problem is that what's in your _repository_ has CRs.
Yes, but does that really have to be an issue? Is there any technical or 
practical reason you can think of that the repository shouldn't ignore 
those CRs?

> I wonder if this is a fundamental misunderstanding of how the CRLF
> handling in git works. It is not "magically make me not care about line
> endings anymore". It is "the canonical version in the repo is LF-only.
> Strip anything coming into the repository to match that, and
> (optionally) add CR to anything going out to the filesystem for my
> convenience". But you need a flag day to update the in-repository
> versions to the new scheme.
>
> -Peff
You're right, we can't magically avoid all the line ending issues that 
people will run into. In this case, though, I think git can sidestep a 
fairly obnoxious problem. My example was simple, but when you've got 
multiple branches that need to be rebased/merged, it can get pretty 
hairy. The repository will never be truly "clean" unless you rewrite the 
whole thing (using filter-branch, for instance).

Maybe my above suggestion is more of a feature request than a bug, but 
there is the obvious bug that after changing .gitattributes, git still 
doesn't notice that files are "modified" until you modify them again in 
some way (touch works). I only noticed the CRs in our own repository 
after I tried to rebase a branch and got strange errors. To make git 
notice all the files, I had to "find . -type f -exec touch {} \;".

Re: Bug report

[Jeff King]

On Sat, Oct 06, 2012 at 09:23:59PM -0500, John Whitney wrote:

> >You said in your test script:
> >
> >   # Committing test.txt or clearing .gitattributes does clear
> >   # the "modified" status, but those options are undesirable
> >
> >Why is the commit undesirable? You have decided that CRs will no longer
> >be tolerated in your repository (by setting .gitattributes). Now you
> >need to record that change in history with a commit that strips out the
> >CRs.
> In some cases it's undesirable. In my example, all I want to do is
> merge in the change that deletes the file, so I don't want to have to
> add that extra commit when I'm just going to delete the file anyway.

Yes, but that is conflating two operations. You only don't want to do
the commit because you are anticipating what is coming next (the
cherry-picked deletion). But if you want to conflate, then you could
also realize that you can simply delete the file, CRs or no, and you do
not need to care about its modified state.

I think a much stronger argument for your position is that the cherry
pick would not happen without a conflict after such a commit, because it
would be deleting files with two different sets of content (the
cherry-pick would want to delete the CR version, but you would not have
that version).

In other words, you want the cherry-pick to happen and ignore the
modification that could be committed, because you know the modification
is not relevant (but git does not). But there is not a way to do that
(even once you overcome the confusion), because the usual way to do so
is to drop the local modification with "git reset" (which would not work
in this case).

> >It is not about having CRs in the working tree file. Those are now
> >considered uninteresting and stripped by git when comparing to the HEAD.
> >The problem is that what's in your _repository_ has CRs.
> Yes, but does that really have to be an issue? Is there any technical
> or practical reason you can think of that the repository shouldn't
> ignore those CRs?

It's significantly less efficient. Right now git only has to do the
conversion when updating the index cache of what's on the filesystem
(i.e., when it would be doing a sha1 over the file contents _anyway_).
And then it can compare sha1s internally, because it knows that all of
the sha1s it has computed are for the canonical in-repo versions of the
file.

If we assume that the in-repo file might need to have CRs stripped, then
we need to actually follow up every sha1 mismatch with an actual content
diff in order to discover if it really is different or not. We could
cache the "true" sha1 of the canonical stripped version to avoid this,
but now we are getting much more complex. In most cases it is sufficient
to just commit the cleaned up contents and then never worry about it
again.

> You're right, we can't magically avoid all the line ending issues
> that people will run into. In this case, though, I think git can
> sidestep a fairly obnoxious problem. My example was simple, but when
> you've got multiple branches that need to be rebased/merged, it can
> get pretty hairy. The repository will never be truly "clean" unless
> you rewrite the whole thing (using filter-branch, for instance).

Right. Git's current approach is very hairy when you are looking at
history that crosses a CRLF flag-day boundary. It's definitely a
weakness of the canonicalization approach. But other approaches also
have downsides; I don't want to catalogue them all here, but you can
certainly search the archive for various discussions and flamewars about
how line endings are handled.

> Maybe my above suggestion is more of a feature request than a bug,

Fair enough. I think your complaint is real, but I think nobody has been
clever enough yet to devise a solution that does not have too many other
downsides. And of course you are free to propose such an approach if you
have thought of one. :)

> but there is the obvious bug that after changing .gitattributes, git
> still doesn't notice that files are "modified" until you modify them
> again in some way (touch works). I only noticed the CRs in our own
> repository after I tried to rebase a branch and got strange errors.
> To make git notice all the files, I had to "find . -type f -exec
> touch {} \;".

I think the idea has been floated before of unconditionally refreshing
the index when you update the crlf config via "git config". But of
course that can only fix a fraction of the cases. You might edit it with
an editor. Or they may be new lines in .gitattributes. Or a change of
wildcard lines in .gitattributes.

Really, the issue is that the index contains a cache of what's in the
files that is considered valid unless the stat information of the file
changes. But that is obviously not the full story, as the
canonicalization rules (CRLF handling or smudge/clean filters) can
change, too, and that is not considered as part of the cache's validity.
Doing it "right" would mean that anytime the attributes or config files
changed, we would consider the cache entry dirty and re-read (and
re-canonicalize) the file.

But that has either:

  1. Bad complexity. It means our cache validity needs to know about
     exactly which rules were applied to yield the cached sha1. And
     those rules can be complex, consisting of wildcard matching,
     cross-referencing custom filters from config, etc.

  2. Bad performance. If you instead just invalidate cached sha1s when
     the gitattributes or .git/config file changes, you catch way too
     many cases. E.g., if you checkout a branch that changes
     .gitattributes, we have to re-read every file in the repository,
     even though most of them will not be affected.

So I think it's possible to handle this case correctly, but doing it
right is quite complex. So we have the "just manually poke the files
when you make such a change". Which is a horrible user experience, but
works OK in practice (and many people do not run into it at all, because
on new projects they set the filter attributes very early on, before
they have an existing history).

IOW, no, it is not pretty, but these are all known issues that nobody
has felt it worth tackling yet.

-Peff

Re: Bug report

[John Whitney]

On 10/7/12 6:52 PM, Jeff King wrote:
>> Yes, but does that really have to be an issue? Is there any technical 
>> or practical reason you can think of that the repository shouldn't 
>> ignore those CRs? 
> It's significantly less efficient. Right now git only has to do the
> conversion when updating the index cache of what's on the filesystem
> (i.e., when it would be doing a sha1 over the file contents _anyway_).
> And then it can compare sha1s internally, because it knows that all of
> the sha1s it has computed are for the canonical in-repo versions of the
> file.
>
> If we assume that the in-repo file might need to have CRs stripped, then
> we need to actually follow up every sha1 mismatch with an actual content
> diff in order to discover if it really is different or not. We could
> cache the "true" sha1 of the canonical stripped version to avoid this,
> but now we are getting much more complex. In most cases it is sufficient
> to just commit the cleaned up contents and then never worry about it
> again.
>
>> You're right, we can't magically avoid all the line ending issues
>> that people will run into. In this case, though, I think git can
>> sidestep a fairly obnoxious problem. My example was simple, but when
>> you've got multiple branches that need to be rebased/merged, it can
>> get pretty hairy. The repository will never be truly "clean" unless
>> you rewrite the whole thing (using filter-branch, for instance).
> Right. Git's current approach is very hairy when you are looking at
> history that crosses a CRLF flag-day boundary. It's definitely a
> weakness of the canonicalization approach. But other approaches also
> have downsides; I don't want to catalogue them all here, but you can
> certainly search the archive for various discussions and flamewars about
> how line endings are handled.
>
>> Maybe my above suggestion is more of a feature request than a bug,
> Fair enough. I think your complaint is real, but I think nobody has been
> clever enough yet to devise a solution that does not have too many other
> downsides. And of course you are free to propose such an approach if you
> have thought of one. :)
>
>> but there is the obvious bug that after changing .gitattributes, git
>> still doesn't notice that files are "modified" until you modify them
>> again in some way (touch works). I only noticed the CRs in our own
>> repository after I tried to rebase a branch and got strange errors.
>> To make git notice all the files, I had to "find . -type f -exec
>> touch {} \;".
> I think the idea has been floated before of unconditionally refreshing
> the index when you update the crlf config via "git config". But of
> course that can only fix a fraction of the cases. You might edit it with
> an editor. Or they may be new lines in .gitattributes. Or a change of
> wildcard lines in .gitattributes.
>
> Really, the issue is that the index contains a cache of what's in the
> files that is considered valid unless the stat information of the file
> changes. But that is obviously not the full story, as the
> canonicalization rules (CRLF handling or smudge/clean filters) can
> change, too, and that is not considered as part of the cache's validity.
> Doing it "right" would mean that anytime the attributes or config files
> changed, we would consider the cache entry dirty and re-read (and
> re-canonicalize) the file.
>
> But that has either:
>
>    1. Bad complexity. It means our cache validity needs to know about
>       exactly which rules were applied to yield the cached sha1. And
>       those rules can be complex, consisting of wildcard matching,
>       cross-referencing custom filters from config, etc.
>
>    2. Bad performance. If you instead just invalidate cached sha1s when
>       the gitattributes or .git/config file changes, you catch way too
>       many cases. E.g., if you checkout a branch that changes
>       .gitattributes, we have to re-read every file in the repository,
>       even though most of them will not be affected.
>
> So I think it's possible to handle this case correctly, but doing it
> right is quite complex. So we have the "just manually poke the files
> when you make such a change". Which is a horrible user experience, but
> works OK in practice (and many people do not run into it at all, because
> on new projects they set the filter attributes very early on, before
> they have an existing history).
>
> IOW, no, it is not pretty, but these are all known issues that nobody
> has felt it worth tackling yet.
>
> -Peff

Thank you very much for your detailed explanations. I suspected that 
efficiency concerns might be preventing a clean solution.

How about this idea... When git stores files, it could include a bit of 
metadata that tells it whether the file is a binary blob or text. 
(Perhaps it already does this?) If a binary blob (in the repository) is 
being compared with a text file (on the filesystem), git could 
re-process the blob and get the "sha1 of the canonical stripped 
version". In all other situations, the original SHA1 should be correct, 
since git already removes CRs from the line endings in files it 
recognizes as text.

I would think that this solution would have no performance penalty for 
"fixed" repositories. (It would only have a small performance hit when 
binary blobs are compared against text files, which is rare even in 
broken repositories.) Git could even throw a warning like: "File xyz.txt 
was originally stored as a binary blob."

What do you think?

    ---John

Re: Bug report

[John Whitney]

On 10/9/12 12:17 PM, John Whitney wrote:
> Thank you very much for your detailed explanations. I suspected that 
> efficiency concerns might be preventing a clean solution.
>
> How about this idea... When git stores files, it could include a bit 
> of metadata that tells it whether the file is a binary blob or text. 
> (Perhaps it already does this?) If a binary blob (in the repository) 
> is being compared with a text file (on the filesystem), git could 
> re-process the blob and get the "sha1 of the canonical stripped 
> version". In all other situations, the original SHA1 should be 
> correct, since git already removes CRs from the line endings in files 
> it recognizes as text.
>
> I would think that this solution would have no performance penalty for 
> "fixed" repositories. (It would only have a small performance hit when 
> binary blobs are compared against text files, which is rare even in 
> broken repositories.) Git could even throw a warning like: "File 
> xyz.txt was originally stored as a binary blob."
>
> What do you think?
>
>    ---John
>
I'm going to reply to myself, to save you the trouble of replying. 
(You've been very helpful and I do appreciate it.)

I guess the problem with this idea is that git doesn't have any way to 
distinguish between binary blobs and text files in the repository. I 
think it would be useful information, but I guess that bridge burned a 
long time ago. So any metadata would have to be stored separately. Jeff, 
that's roughly equivalent to your idea of caching, which would take a 
lot of work to implement.

Thank you so much for helping me to understand the reason git behaves 
the way it does. It's a great tool!

    ---John

Re: Bug report

[Andrew Wong]

On 10/04/2012 12:35 AM, John Whitney wrote:
> I just ran into a problem that I'm pretty sure is a bug in git. Just 
> read and run this (fairly trivial) shell script to replicate.
I tried your steps on a Mac, but I wasn't able to produce the issue. 
Perhaps I don't have the right CRLF configs to trigger the issue. I've 
tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What git 
version are you using? And, if any, what are your configs for 
"core.eol", "core.safecrlf", and "core.autocrlf" ?

What Phil said also makes sense though.

Re: Bug report

[John Whitney]

Andrew,

Thanks for checking this on your machine.

This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and run the script like this: "sh git_failure.sh"

    ---John


On 10/4/12 10:21 AM, Andrew Wong wrote:
> On 10/04/2012 12:35 AM, John Whitney wrote:
>> I just ran into a problem that I'm pretty sure is a bug in git. Just 
>> read and run this (fairly trivial) shell script to replicate.
> I tried your steps on a Mac, but I wasn't able to produce the issue. 
> Perhaps I don't have the right CRLF configs to trigger the issue. I've 
> tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What git 
> version are you using? And, if any, what are your configs for 
> "core.eol", "core.safecrlf", and "core.autocrlf" ?
>
> What Phil said also makes sense though.
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

Re: Bug report

[John Whitney]

Andrew,

I forgot to say that all of the config settings
are not changed from the default.

    ---John


On 10/4/12 11:16 AM, John Whitney wrote:
> Andrew,
>
> Thanks for checking this on your machine.
>
> This problem occurs on Mac, Windows, and Linux, and
> with multiple versions of git. Note that in my script a CR
> is appended to test.txt. On the Mac, you can generate this
> in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
> just download and run the script like this: "sh git_failure.sh"
>
>    ---John
>
>
> On 10/4/12 10:21 AM, Andrew Wong wrote:
>> On 10/04/2012 12:35 AM, John Whitney wrote:
>>> I just ran into a problem that I'm pretty sure is a bug in git. Just 
>>> read and run this (fairly trivial) shell script to replicate.
>> I tried your steps on a Mac, but I wasn't able to produce the issue. 
>> Perhaps I don't have the right CRLF configs to trigger the issue. 
>> I've tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What 
>> git version are you using? And, if any, what are your configs for 
>> "core.eol", "core.safecrlf", and "core.autocrlf" ?
>>
>> What Phil said also makes sense though.
>>
>
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

Re: Bug report

[Andrew Wong]

On 10/04/2012 12:16 PM, John Whitney wrote:
> This problem occurs on Mac, Windows, and Linux, and
> with multiple versions of git. Note that in my script a CR
> is appended to test.txt. On the Mac, you can generate this
> in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
> just download and run the script like this: "sh git_failure.sh"
Ah, yes. I can reproduce the problem. I was pasting the lines from your 
script. And I saw a new line in the shell when I pasted, so I thought 
the ^M was kept properly. But somewhere during the pasting, the ^M must 
have got translated to a \n automatically. Silly me.

bug report

[Manoel Pedro]

Sep  1 20:24:07 sa kernel: [ 8034.244618] ------------[ cut here ]------------
Sep  1 20:24:07 sa kernel: [ 8034.244638] WARNING: at
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.5.3/linux-3.5/fs/btrfs/extent-tree.c:6221
use_block_rsv+0x15e/0x170 [btrfs]()
Sep  1 20:24:07 sa kernel: [ 8034.244640] Hardware name: Latitude 120L
Sep  1 20:24:07 sa kernel: [ 8034.244642] Modules linked in: loop
af_packet fuse arc4 cpufreq_conservative cpufreq_userspace
cpufreq_powersave b43 mac80211 cfg80211 rfkill bcma iTCO_wdt gpio_ich
iTCO_vendor_support sr_mod cdrom sg b44 dell_laptop usb_storage dcdbas
uas joydev ssb snd_hda_codec_idt mmc_core pcmcia pcmcia_core pcspkr
lpc_ich mfd_core snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
snd_timer battery ac snd soundcore snd_page_alloc acpi_cpufreq mperf
microcode binfmt_misc pciehp pci_hotplug autofs4 i915 drm_kms_helper
drm i2c_algo_bit thermal button video processor thermal_sys
scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh btrfs
zlib_deflate libcrc32c ata_generic ata_piix
Sep  1 20:24:07 sa kernel: [ 8034.244690] Pid: 314, comm:
btrfs-balance Tainted: G        W    3.5.3-40-desktop #1
Sep  1 20:24:07 sa kernel: [ 8034.244692] Call Trace:
Sep  1 20:24:07 sa kernel: [ 8034.244698]  [<c02055b3>]
try_stack_unwind+0x173/0x180
Sep  1 20:24:07 sa kernel: [ 8034.244704]  [<c02042c7>] dump_trace+0x47/0xf0
Sep  1 20:24:07 sa kernel: [ 8034.244709]  [<c020560b>]
show_trace_log_lvl+0x4b/0x60
Sep  1 20:24:07 sa kernel: [ 8034.244714]  [<c0205638>] show_trace+0x18/0x20
Sep  1 20:24:07 sa kernel: [ 8034.244720]  [<c070e144>] dump_stack+0x6d/0x72
Sep  1 20:24:07 sa kernel: [ 8034.244725]  [<c0234ea8>]
warn_slowpath_common+0x78/0xb0
Sep  1 20:24:07 sa kernel: [ 8034.244730]  [<c0234efb>]
warn_slowpath_null+0x1b/0x20
Sep  1 20:24:07 sa kernel: [ 8034.244750]  [<f7cd8a2e>]
use_block_rsv+0x15e/0x170 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244817]  [<f7cdc92c>]
btrfs_alloc_free_block+0x3c/0x2a0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244888]  [<f7cc7ba8>]
__btrfs_cow_block+0x158/0x5c0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244931]  [<f7cc80e9>]
btrfs_cow_block+0xd9/0x250 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244982]  [<f7d392e7>]
do_relocation+0x447/0x500 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.251298]  [<f7d395bc>]
relocate_tree_block+0x21c/0x260 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.251567]  [<f7d3da8d>]
relocate_tree_blocks+0x11d/0x180 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.251841]  [<f7d3e89e>]
relocate_block_group+0x1fe/0x5a0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252125]  [<f7d3edea>]
btrfs_relocate_block_group+0x1aa/0x300 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252397]  [<f7d19b35>]
btrfs_relocate_chunk.isra.51+0x55/0x410 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252613]  [<f7d1e6b2>]
btrfs_shrink_device+0x262/0x480 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252834]  [<f7d1e9a1>]
__btrfs_balance+0xd1/0x4a0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.257807]  [<f7d1f0f7>]
btrfs_balance+0x387/0x550 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.259855]  [<f7d1f330>]
balance_kthread+0x70/0x80 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.260082]  [<c02545fe>] kthread+0x6e/0x80
Sep  1 20:24:07 sa kernel: [ 8034.260092]  [<c072bf66>]
kernel_thread_helper+0x6/0xd
Sep  1 20:24:07 sa kernel: [ 8034.260098] ---[ end trace dc79c5cfcfeff6c9 ]---

Bug report

[mr.shroom]

SATA for kernel(s) 3.5+ has an issue with IRQ Balancing on AMD SB710
with motherboard ASRock m3a770d3.

The problem started while using Arch linux, after going back to Debian
it persisted.  I had tried to find problems with the bug but couldn't
find any direct help online.  I had a break when finding similar bugs
on other sites stating that IRQ Balancing might be the fault.  So I
tried ACPI_IRQ_NOBALANCE in the kernel boot parameters and so far the
issue has stopped.

Linux version 3.6.0-rc2 (mboy@debian) (gcc version 4.7.1 (Debian
4.7.1-6) ) #1 SMP Sat Aug 18 00:46:06 CDT 2012

Aug 20 12:32:08 debian kernel: [42238.075368] ata4.00: exception Emask
0x0 SAct 0x7f SErr 0x0 action 0x6 frozen
Aug 20 12:32:08 debian kernel: [42238.075373] ata4.00: failed command:
WRITE FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075377] ata4.00: cmd
61/08:00:c8:0a:89/00:00:01:00:00/40 tag 0 ncq 4096 out
Aug 20 12:32:08 debian kernel: [42238.075377]          res
40/00:00:00:4f:c2/00:00:00:4f:c2/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075379] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075381] ata4.00: failed command:
WRITE FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075384] ata4.00: cmd
61/08:08:f8:cb:8a/00:00:03:00:00/40 tag 1 ncq 4096 out
Aug 20 12:32:08 debian kernel: [42238.075384]          res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075386] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075388] ata4.00: failed command:
WRITE FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075391] ata4.00: cmd
61/10:10:80:95:86/00:00:08:00:00/40 tag 2 ncq 8192 out
Aug 20 12:32:08 debian kernel: [42238.075391]          res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075393] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075394] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075397] ata4.00: cmd
60/60:18:60:71:62/00:00:00:00:00/40 tag 3 ncq 49152 in
Aug 20 12:32:08 debian kernel: [42238.075397]          res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075399] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075401] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075404] ata4.00: cmd
60/08:20:c8:71:62/00:00:00:00:00/40 tag 4 ncq 4096 in
Aug 20 12:32:08 debian kernel: [42238.075404]          res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075406] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075407] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075410] ata4.00: cmd
60/18:28:d8:71:62/00:00:00:00:00/40 tag 5 ncq 12288 in
Aug 20 12:32:08 debian kernel: [42238.075410]          res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075412] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075413] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075417] ata4.00: cmd
60/08:30:f8:71:62/00:00:00:00:00/40 tag 6 ncq 4096 in
Aug 20 12:32:08 debian kernel: [42238.075417]          res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075418] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075422] ata4: hard resetting link

After it would reset, it would try SATA I, fail, then mount the drive
as RO.  I'm running a Phenom II on Debian Wheezy with a bit of Sid,
don't have the time at the moment to get a better grasp on what you
need for a proper bug report but I hope this helps.

Re: Bug report

[Randy Dunlap]

(cc-ing linux-ide mailing list)


On 08/20/2012 03:31 PM, mr.shroom wrote:

> SATA for kernel(s) 3.5+ has an issue with IRQ Balancing on AMD SB710
> with motherboard ASRock m3a770d3.
> 
> The problem started while using Arch linux, after going back to Debian
> it persisted.  I had tried to find problems with the bug but couldn't
> find any direct help online.  I had a break when finding similar bugs
> on other sites stating that IRQ Balancing might be the fault.  So I
> tried ACPI_IRQ_NOBALANCE in the kernel boot parameters and so far the
> issue has stopped.
> 
> Linux version 3.6.0-rc2 (mboy@debian) (gcc version 4.7.1 (Debian
> 4.7.1-6) ) #1 SMP Sat Aug 18 00:46:06 CDT 2012
> 
> Aug 20 12:32:08 debian kernel: [42238.075368] ata4.00: exception Emask
> 0x0 SAct 0x7f SErr 0x0 action 0x6 frozen
> Aug 20 12:32:08 debian kernel: [42238.075373] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075377] ata4.00: cmd
> 61/08:00:c8:0a:89/00:00:01:00:00/40 tag 0 ncq 4096 out
> Aug 20 12:32:08 debian kernel: [42238.075377]          res
> 40/00:00:00:4f:c2/00:00:00:4f:c2/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075379] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075381] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075384] ata4.00: cmd
> 61/08:08:f8:cb:8a/00:00:03:00:00/40 tag 1 ncq 4096 out
> Aug 20 12:32:08 debian kernel: [42238.075384]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075386] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075388] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075391] ata4.00: cmd
> 61/10:10:80:95:86/00:00:08:00:00/40 tag 2 ncq 8192 out
> Aug 20 12:32:08 debian kernel: [42238.075391]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075393] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075394] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075397] ata4.00: cmd
> 60/60:18:60:71:62/00:00:00:00:00/40 tag 3 ncq 49152 in
> Aug 20 12:32:08 debian kernel: [42238.075397]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075399] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075401] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075404] ata4.00: cmd
> 60/08:20:c8:71:62/00:00:00:00:00/40 tag 4 ncq 4096 in
> Aug 20 12:32:08 debian kernel: [42238.075404]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075406] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075407] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075410] ata4.00: cmd
> 60/18:28:d8:71:62/00:00:00:00:00/40 tag 5 ncq 12288 in
> Aug 20 12:32:08 debian kernel: [42238.075410]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075412] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075413] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075417] ata4.00: cmd
> 60/08:30:f8:71:62/00:00:00:00:00/40 tag 6 ncq 4096 in
> Aug 20 12:32:08 debian kernel: [42238.075417]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075418] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075422] ata4: hard resetting link
> 
> After it would reset, it would try SATA I, fail, then mount the drive
> as RO.  I'm running a Phenom II on Debian Wheezy with a bit of Sid,
> don't have the time at the moment to get a better grasp on what you
> need for a proper bug report but I hope this helps.
> --


-- 
~Randy

Re: Bug report

[Alan Cox]

On Mon, 20 Aug 2012 15:43:35 -0700
Randy Dunlap <rdunlap@xenotime.net> wrote:

> (cc-ing linux-ide mailing list)

Classic "no IRQ being delivered" - looks like a platform IRQ routing
problem

Re: Bug report

[Borislav Petkov]

Adding linux-ide.

Please send also full dmesg of the box.

Thanks.

On Mon, Aug 20, 2012 at 05:31:44PM -0500, mr.shroom wrote:
> SATA for kernel(s) 3.5+ has an issue with IRQ Balancing on AMD SB710
> with motherboard ASRock m3a770d3.
> 
> The problem started while using Arch linux, after going back to Debian
> it persisted.  I had tried to find problems with the bug but couldn't
> find any direct help online.  I had a break when finding similar bugs
> on other sites stating that IRQ Balancing might be the fault.  So I
> tried ACPI_IRQ_NOBALANCE in the kernel boot parameters and so far the
> issue has stopped.
> 
> Linux version 3.6.0-rc2 (mboy@debian) (gcc version 4.7.1 (Debian
> 4.7.1-6) ) #1 SMP Sat Aug 18 00:46:06 CDT 2012
> 
> Aug 20 12:32:08 debian kernel: [42238.075368] ata4.00: exception Emask
> 0x0 SAct 0x7f SErr 0x0 action 0x6 frozen
> Aug 20 12:32:08 debian kernel: [42238.075373] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075377] ata4.00: cmd
> 61/08:00:c8:0a:89/00:00:01:00:00/40 tag 0 ncq 4096 out
> Aug 20 12:32:08 debian kernel: [42238.075377]          res
> 40/00:00:00:4f:c2/00:00:00:4f:c2/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075379] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075381] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075384] ata4.00: cmd
> 61/08:08:f8:cb:8a/00:00:03:00:00/40 tag 1 ncq 4096 out
> Aug 20 12:32:08 debian kernel: [42238.075384]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075386] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075388] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075391] ata4.00: cmd
> 61/10:10:80:95:86/00:00:08:00:00/40 tag 2 ncq 8192 out
> Aug 20 12:32:08 debian kernel: [42238.075391]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075393] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075394] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075397] ata4.00: cmd
> 60/60:18:60:71:62/00:00:00:00:00/40 tag 3 ncq 49152 in
> Aug 20 12:32:08 debian kernel: [42238.075397]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075399] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075401] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075404] ata4.00: cmd
> 60/08:20:c8:71:62/00:00:00:00:00/40 tag 4 ncq 4096 in
> Aug 20 12:32:08 debian kernel: [42238.075404]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075406] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075407] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075410] ata4.00: cmd
> 60/18:28:d8:71:62/00:00:00:00:00/40 tag 5 ncq 12288 in
> Aug 20 12:32:08 debian kernel: [42238.075410]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075412] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075413] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075417] ata4.00: cmd
> 60/08:30:f8:71:62/00:00:00:00:00/40 tag 6 ncq 4096 in
> Aug 20 12:32:08 debian kernel: [42238.075417]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075418] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075422] ata4: hard resetting link
> 
> After it would reset, it would try SATA I, fail, then mount the drive
> as RO.  I'm running a Phenom II on Debian Wheezy with a bit of Sid,
> don't have the time at the moment to get a better grasp on what you
> need for a proper bug report but I hope this helps.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Regards/Gruss,
    Boris.

Bug report

[artem rus]

Problem: GPU hangs
Chipset: Intel 845 GV + ICH4
Video: integrated
Linux kernel: 3.3.5, 3.4.7 (no bug difference)
X.Org X Server 1.7.7
How to reproduce: First Xorg start is ok, bug happens after Xorg restart
Syslog:
Aug  1 17:13:18 nika kernel: [ 1049.248033]
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU
hung
Aug  1 17:13:18 nika kernel: [ 1049.248045] [drm] capturing error
event; look for more information in /debug/dri/0/i915_error_state
Aug  1 17:13:20 nika kernel: [ 1051.736033]
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU
hung
Aug  1 17:13:20 nika kernel: [ 1051.740699] [drm:i915_reset] *ERROR*
GPU hanging too fast, declaring wedged!
Aug  1 17:13:20 nika kernel: [ 1051.740706] [drm:i915_reset] *ERROR*
Failed to reset chip.

Aug  1 17:15:57 nika kernel: [ 1208.915038] WARNING: at
/root/build_scgs/build/linux-3.4.7/drivers/gpu/drm/i915/i915_gem.c:2410
i915_gem_object_put_fence+0x5b/0x86 [i915]()
Aug  1 17:15:57 nika kernel: [ 1208.915042] Hardware name:
Aug  1 17:15:57 nika kernel: [ 1208.915045] Modules linked in: fuse
ext3 jbd microcode i915 snx(O) i2c_i801 evdev pcspkr parport_pc
parport drm_kms_helper processor drm rng_core i2c_algo_bit button
intel_agp i2c_core intel_gtt video agpgart ext2 mbcache usb_storage
uas usbhid hid sd_mod crc_t10dif via_rhine mii ata_piix libata
uhci_hcd scsi_mod ehci_hcd usbcore thermal usb_common fan thermal_sys
[last unloaded: scsi_wait_scan]
Aug  1 17:15:57 nika kernel: [ 1208.915104] Pid: 1583, comm: Xorg
Tainted: G           O 3.4.7-1-nika #1
Aug  1 17:15:57 nika kernel: [ 1208.915107] Call Trace:
Aug  1 17:15:57 nika kernel: [ 1208.915118]  [<c101a65e>] ?
warn_slowpath_common+0x68/0x79
Aug  1 17:15:57 nika kernel: [ 1208.915132]  [<f8e016c6>] ?
i915_gem_object_put_fence+0x5b/0x86 [i915]
Aug  1 17:15:57 nika kernel: [ 1208.915137]  [<c101a67c>] ?
warn_slowpath_null+0xd/0x10
Aug  1 17:15:57 nika kernel: [ 1208.915150]  [<f8e016c6>] ?
i915_gem_object_put_fence+0x5b/0x86 [i915]
Aug  1 17:15:57 nika kernel: [ 1208.915164]  [<f8e025b7>] ?
i915_gem_object_unbind+0x9a/0x13f [i915]
Aug  1 17:15:57 nika kernel: [ 1208.915177]  [<f8e02671>] ?
i915_gem_free_object_tail+0x15/0xae [i915]
Aug  1 17:15:57 nika kernel: [ 1208.915195]  [<f85a4f78>] ?
drm_gem_object_free+0x1d/0x1e [drm]
Aug  1 17:15:57 nika kernel: [ 1208.915212]  [<f8e0a8ef>] ?
drm_gem_object_unreference_unlocked+0x26/0x32 [i915]
Aug  1 17:15:57 nika kernel: [ 1208.915226]  [<f8e0baf5>] ?
intel_user_framebuffer_destroy+0x10/0x18 [i915]
Aug  1 17:15:57 nika kernel: [ 1208.915240]  [<f85ae369>] ?
drm_fb_release+0x3a/0x52 [drm]
Aug  1 17:15:57 nika kernel: [ 1208.915250]  [<f85a48b8>] ?
drm_release+0x289/0x4b4 [drm]
Aug  1 17:15:57 nika kernel: [ 1208.915257]  [<c109fe1a>] ? fput+0xd4/0x195
Aug  1 17:15:57 nika kernel: [ 1208.915261]  [<c109dbb3>] ? filp_close+0x52/0x58
Aug  1 17:15:57 nika kernel: [ 1208.915267]  [<c101cb79>] ?
put_files_struct+0x4c/0x90
Aug  1 17:15:57 nika kernel: [ 1208.915271]  [<c101cf8b>] ? do_exit+0x1ec/0x60f
Aug  1 17:15:57 nika kernel: [ 1208.915276]  [<c1001bed>] ?
restore_sigcontext+0xbf/0xec
Aug  1 17:15:57 nika kernel: [ 1208.915280]  [<c100250c>] ?
sys_sigreturn+0x62/0x86
Aug  1 17:15:57 nika kernel: [ 1208.915285]  [<c101d569>] ?
do_group_exit+0x3e/0x5f
Aug  1 17:15:57 nika kernel: [ 1208.915289]  [<c101d59b>] ?
sys_exit_group+0x11/0x11
Aug  1 17:15:57 nika kernel: [ 1208.915294]  [<c125165c>] ? syscall_call+0x7/0xb
Aug  1 17:15:57 nika kernel: [ 1208.915298] ---[ end trace d758b3315db37a86 ]---

Bug report

[Hendrik Knackstedt]

Hi everybody!

Since bugzilla.kernel.org still seems to be down and I don't know a 
better place for this I reporting this bug here for now.

Suspend used to work on my Acer Aspire 5750G when I've closed the 
laptop's lid but doesn't work anymore. So this is a regression bug.

You'll find further informationen and debugging protocols here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882149

Please help me to solve this bug or redirect me to the right place for 
this bug report.

Thanks!

Hendrik

Bug Report

[Charles Opondo]

There appears to be a bug with Linux 2.6.38-11-generic kernel; my synaptic touchpad appears not to work with this kernel. I'm not sure if this is a problem specific to my Asus B50A laptop or a general one. Have you had any similar reports?

Re: Bug Report

[Bjorn Helgaas]

On Tue, Jul 19, 2011 at 11:34 AM, Charles Opondo
<charles.opondo@lshtm.ac.uk> wrote:
> There appears to be a bug with Linux 2.6.38-11-generic kernel; my synaptic touchpad appears not to work with this kernel. I'm not sure if this is a problem specific to my Asus B50A laptop or a general one. Have you had any similar reports?

Is this a regression, i.e., did the touchpad work with a previous
kernel and only started failing with 2.6.38?  Do you have a way to
test a current kernel, e.g., 3.0-rc7 to see whether it's already been
fixed?

I assume this is a USB device, so I cc'd linux-usb.  If you can
collect the complete dmesg logs from the newest kernel that works and
from 2.6.38, and compare them, there might be a clue.

Bjorn

bug report

[Larry D'Anna]

So i made a filesystem image 

 $ dd if=/dev/zero of=root_fs bs=1024 count=$(expr 1024 \* 1024)
 $ mkfs.btrfs root_fs 

Then I put some debian on it (my kernel is 2.6.35-27-generic #48-Ubuntu) 

 $ mkdir root 
 $ mount -o loop root_fs root 
 $ debootstrap sid root 
 $ umount root

Then i run uml.....   (2.6.35-1um-0ubuntu1)

 $ linux single eth0=tuntap,tap0,fe:fd:f0:00:00:01

and then try to apt-get some stuff, and the result is this:

btrfs csum failed ino 17498 off 2412544 csum 491052325 private 446722121
btrfs csum failed ino 17498 off 2416640 csum 2077462867 private 906054605
btrfs csum failed ino 17498 off 2420736 csum 263316283 private 2215839539
btrfs csum failed ino 17498 off 2424832 csum 4177088190 private 2414263107
btrfs csum failed ino 17498 off 2428928 csum 4028205539 private 3560605623
btrfs csum failed ino 17498 off 2433024 csum 1724529595 private 200634979
btrfs csum failed ino 17498 off 2437120 csum 4038631380 private 2927872002
btrfs csum failed ino 17498 off 2441216 csum 2616837020 private 729736037
btrfs csum failed ino 17498 off 2498560 csum 2566472073 private 3417075259
btrfs csum failed ino 17498 off 2502656 csum 2566472073 private 1410567947


 $ find / -mount -inum 17498  
 /var/cache/apt/srcpkgcache.bin

I've gone through this twice now, so it's repeatable at least.  I know 2.6.35 is
kinda old but was this kind of thing to be expected back then?  


      --larry

Re: bug report

[Helmut Hullen]

Hallo, Larry,

Du meintest am 05.04.11:

[...]

> and then try to apt-get some stuff, and the result is this:

> btrfs csum failed ino 17498 off 2412544 csum 491052325 private
> 446722121
> btrfs csum failed ino 17498 off 2416640 csum 2077462867
> private 906054605

[...]

> I've gone through this twice now, so it's repeatable at least.  I
> know 2.6.35 is kinda old but was this kind of thing to be expected
> back then?

First try an actual kernel; I prefer 2.6.38.1

Viele Gruesse!
Helmut

Bug Report

[Dipl.-Ing. Michael Niederle]

Hi!

Today I installed SIMPLUX on a freshly formatted 30GB partition on a pen drive.
I updated the whole system, compiled and installed the final version of the
2.6.30 kernel. I did not apply any further nilfs-patches. Everything worked
fine. Then (using the new kernel) I deleted several GB of old data. The garbage
collection worked really slow, so I changed the settings in nilfs_cleanerd.conf
as follows:

protection_period	900
selection_policy	timestamp
nsegments_per_clean	10
cleaning_interval	5
use_mmap
log_priority		info

Then I restarted the cleaner daemon and was happy to see now much more activity
on the pen-drive. The garbage collection claimed back MB after MB. I thought it
would take some time for the garbage collection to complete and left the room.
When I returned the machine was completely crashed (black screen - maybe due
to the screen saver). I could only reboot it via "ctrl-alt-sysrqst USB".

There was no background job during the time of the crash - just an idling
X-desktop (iceWM - so only very few running daemons).

The next reboot took half an hour! Here an excerpt from the kernel
log:

[    2.407501] usb-storage: device scan complete
[    2.456443] sd 2:0:0:1: [sdd] Attached SCSI removable disk
[ 1759.409004] segctord starting. Construction interval = 5 seconds, CP frequenc
[ 1759.421950] NILFS warning: mounting unchecked fs
[ 1759.456071] NILFS: recovery complete.

It seems nilfs read the whole partition - byte for byte. This would take
approximately the time spent. Wouldn't it suffice to read all segment headers
to recover? The pen drive can handle more than 2000 reads per second.

Before it (presumably) crashed the system the cleaner daemon had done a
nice job - freeing several GB of unused space (but not yet completed the
garbage collection).

Greetings, Michael

Re: Bug Report

[Ryusuke Konishi]

Hi,
On Thu, 11 Jun 2009 19:51:23 +0200, "Dipl.-Ing. Michael Niederle" wrote:
> Hi!
> 
> Today I installed SIMPLUX on a freshly formatted 30GB partition on a
> pen drive.  I updated the whole system, compiled and installed the
> final version of the 2.6.30 kernel. I did not apply any further
> nilfs-patches. Everything worked fine. Then (using the new kernel) I
> deleted several GB of old data. The garbage collection worked really
> slow, so I changed the settings in nilfs_cleanerd.conf as follows:
> 
> protection_period	900
> selection_policy	timestamp
> nsegments_per_clean	10
> cleaning_interval	5
> use_mmap
> log_priority		info
> 
> Then I restarted the cleaner daemon and was happy to see now much
> more activity on the pen-drive. The garbage collection claimed back
> MB after MB. I thought it would take some time for the garbage
> collection to complete and left the room.
>
> When I returned the machine was completely crashed (black screen - maybe due
> to the screen saver). I could only reboot it via "ctrl-alt-sysrqst USB".
> 
> There was no background job during the time of the crash - just an idling
> X-desktop (iceWM - so only very few running daemons).
> 
> The next reboot took half an hour! Here an excerpt from the kernel
> log:
> 
> [    2.407501] usb-storage: device scan complete
> [    2.456443] sd 2:0:0:1: [sdd] Attached SCSI removable disk
> [ 1759.409004] segctord starting. Construction interval = 5 seconds, CP frequenc
> [ 1759.421950] NILFS warning: mounting unchecked fs
> [ 1759.456071] NILFS: recovery complete.
> 
> It seems nilfs read the whole partition - byte for byte. This would take
> approximately the time spent. Wouldn't it suffice to read all segment headers
> to recover? The pen drive can handle more than 2000 reads per second.

It's obviously abnormal.  Nilfs stores a pointer to the latest log in
superblocks.  If power failure occurs, nilfs tries to recover newer
logs by scanning them from the pointed log.

So, your problem seems that neither superblock has been written back
to your pendrive for very long period.

I think the heavy GC load prevented the writeback.

In general, decreasing cleaning_interval is safer than increasing the
nsegments_per_clean to accelerate garbage collection.

Okay, I'll consider enforcing writeback of superblocks to avoid long
duration recovery on mount.

Thank you for reporting this issue.

> Before it (presumably) crashed the system the cleaner daemon had done a
> nice job - freeing several GB of unused space (but not yet completed the
> garbage collection).
> 
> Greetings, Michael

Regards,
Ryusuke Konishi

bug report

[Jeremy]

I was told to post this as a bug report

I dont have mic boost on my creative blaster Audigy SE . I am in Debian 
Squeezey.

Here is my alsa info from the script:
http://www.alsa-project.org/db/?f=a6a639d7543e25379e5ed2e0e9e3fbab35d285cb 

there is actually another mic on my webcam that is usb, if you are wondering 
what that is.

Thanks, Jeremy

bug report

[Todor Gyumyushev]

Hi,


trying to sleep the machine to ram

BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: [<ffffffff802db2ba>] journal_invalidatepage+0x5a/0x32b
PGD 587fe067 PUD 5875e067 PMD 0
Oops: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in: hci_usb rfcomm l2cap bluetooth vboxdrv i915 drm fan 
ac batter
y loop arc4 ecb crypto_blkcipher cryptomgr snd_hda_intel sg snd_pcm 
ath5k snd_ti
mer mac80211 snd usblp sr_mod soundcore evdev ohci1394 thermal led_class 
intel_a
gp processor snd_page_alloc ieee1394 cdrom uhci_hcd ehci_hcd sky2 
thermal_sys cf
g80211 button
Pid: 983, comm: kio_trash Not tainted 2.6.27.4 #4
RIP: 0010:[<ffffffff802db2ba>]  [<ffffffff802db2ba>] 
journal_invalidatepage+0x5a
/0x32b
RSP: 0018:ffff88006eb89d28  EFLAGS: 00010213
RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff88000062b818
RDX: 0000000000000002 RSI: ffff88000062b268 RDI: ffff880001001150
RBP: 00000000000005ab R08: 0000000000000000 R09: 000000000000000e
R10: 00000000000005aa R11: ffffffff802ce2c6 R12: 0000000000000001
R13: 0000000000000009 R14: ffff88007cd94400 R15: ffff88007cd94554
FS:  00007fa9f5b3b6f0(0000) GS:ffffffff8056b5c0(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000020 CR3: 000000004374b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kio_trash (pid: 983, threadinfo ffff88006eb88000, task 
ffff88007da86660)
Stack:  0000000000000005 0000000000000000 ffffe200012361c0 0000000000000000
 0000100000000001 ffff88007cd94424 ffff88000062b268 ffffe200012361c0
 00000000000005ab 00000000000005ab 0000000000000009 ffff88006eb89e30
Call Trace:
 [<ffffffff8026ad66>] ? truncate_complete_page+0x1c/0x45
 [<ffffffff8026ae58>] ? truncate_inode_pages_range+0xc9/0x326
 [<ffffffff802cfe73>] ? ext3_delete_inode+0x17/0xd0
 [<ffffffff802cfe5c>] ? ext3_delete_inode+0x0/0xd0
 [<ffffffff80297642>] ? generic_delete_inode+0x82/0x108
 [<ffffffff8028e314>] ? do_unlinkat+0xdd/0x136
 [<ffffffff8020bfdb>] ? system_call_fastpath+0x16/0x1b


Code: 48 8b 44 24 10 48 8d 57 24 48 8b 40 10 4c 8d bf 54 01 00 00 48 89 
44 24 30                                            48 89 c3 48 89 54 24 
28 31 c0 c7 44 24 20 01 00 00 00 <8b> 53 20 01 c2 89 c0 
89                                            54 24 24 48 39 44 24 08 48 
8b 53 08 48
RIP  [<ffffffff802db2ba>] journal_invalidatepage+0x5a/0x32b
 RSP <ffff88006eb89d28>
CR2: 0000000000000020
---[ end trace 308462b93443026c ]---

Regards,
Todor

bug report

[Todor Gyumyushev]

Sep 25 16:21:09 macmini kernel: ------------[ cut here ]------------
Sep 25 16:21:09 macmini kernel: WARNING: at 
drivers/net/wireless/ath5k/hw.c:3795 ath5k_hw_setup_4word_tx_desc+0x1a3/0x2
50 [ath5k]()
Sep 25 16:21:09 macmini kernel: Modules linked in: ipt_MASQUERADE 
iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_
tables x_tables vboxdrv i915 drm tun kvm acpi_cpufreq hci_usb rfcomm 
l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss sunrp
c exportfs aes_generic fan ac battery microcode firmware_class loop 
usbhid usblp arc4 ecb crypto_blkcipher snd_hda_inte
l cryptomgr tpm_infineon sg tpm snd_pcm_oss snd_mixer_oss ath5k ohci1394 
rng_core thermal processor ieee1394 tpm_bios s
nd_pcm mac80211 sr_mod evdev thermal_sys iTCO_wdt cdrom hwmon 
iTCO_vendor_support cfg80211 snd_timer ehci_hcd uhci_hcd
sky2 intel_agp button snd soundcore snd_page_alloc [last unloaded: 
kvm_intel]
Sep 25 16:21:09 macmini kernel: Pid: 10072, comm: icedove-bin Not 
tainted 2.6.26.5 #1
Sep 25 16:21:09 macmini kernel:
Sep 25 16:21:09 macmini kernel: Call Trace:
Sep 25 16:21:09 macmini kernel: [<ffffffff80235dd4>] 
warn_on_slowpath+0x64/0xc0
Sep 25 16:21:09 macmini kernel: [<ffffffff80346516>] __ratelimit+0x86/0xe0
Sep 25 16:21:09 macmini kernel: [<ffffffffa01063b3>] 
:ath5k:ath5k_hw_setup_4word_tx_desc+0x1a3/0x250
Sep 25 16:21:09 macmini kernel: [<ffffffffa0101fb2>] 
:ath5k:ath5k_tx+0x262/0x4c0
Sep 25 16:21:09 macmini kernel: [<ffffffffa0106210>] 
:ath5k:ath5k_hw_setup_4word_tx_desc+0x0/0x250
Sep 25 16:21:09 macmini kernel: [<ffffffffa009b3bd>] 
:mac80211:__ieee80211_tx+0x2d/0x150
Sep 25 16:21:09 macmini kernel: [<ffffffffa009baf0>] 
:mac80211:ieee80211_master_start_xmit+0x460/0x7a0
Sep 25 16:21:09 macmini kernel: [<ffffffff8042dc2b>] __qdisc_run+0x1db/0x250
Sep 25 16:21:09 macmini kernel: [<ffffffff8041e548>] 
dev_queue_xmit+0x2c8/0x3b0
Sep 25 16:21:09 macmini kernel: [<ffffffffa009c225>] 
:mac80211:ieee80211_subif_start_xmit+0x3f5/0x760
Sep 25 16:21:09 macmini kernel: [<ffffffffa043cbbb>] 
:nf_conntrack:__nf_conntrack_confirm+0x29b/0x2b0
Sep 25 16:21:09 macmini kernel: [<ffffffff80432ab8>] nf_iterate+0x68/0xa0
Sep 25 16:21:09 macmini kernel: [<ffffffff8042dc2b>] __qdisc_run+0x1db/0x250
Sep 25 16:21:09 macmini kernel: [<ffffffff8043e2f0>] 
ip_finish_output+0x0/0x2b0
Sep 25 16:21:09 macmini kernel: [<ffffffff8041e548>] 
dev_queue_xmit+0x2c8/0x3b0
Sep 25 16:21:09 macmini kernel: [<ffffffff8043d78f>] 
ip_push_pending_frames+0x2df/0x410
Sep 25 16:21:09 macmini kernel: [<ffffffff8045d44e>] 
udp_push_pending_frames+0x13e/0x3c0
Sep 25 16:21:09 macmini kernel: [<ffffffff8045ecbc>] udp_sendmsg+0x34c/0x700
Sep 25 16:21:09 macmini kernel: [<ffffffff80311ef7>] 
journal_stop+0x167/0x1e0
Sep 25 16:21:09 macmini kernel: [<ffffffff802bc40a>] __d_lookup+0xaa/0x140
Sep 25 16:21:09 macmini kernel: [<ffffffff8041031b>] sock_sendmsg+0xcb/0x100
Sep 25 16:21:09 macmini kernel: [<ffffffff802bcd62>] dput+0x92/0x140
Sep 25 16:21:09 macmini kernel: [<ffffffff80435da7>] 
__ip_route_output_key+0x167/0xa70
Sep 25 16:21:09 macmini kernel: [<ffffffff8024c040>] 
autoremove_wake_function+0x0/0x30
Sep 25 16:21:09 macmini kernel: [<ffffffff802b29ec>] path_walk+0xbc/0xd0
Sep 25 16:21:09 macmini kernel: [<ffffffff802b2be2>] 
do_path_lookup+0xa2/0x290
Sep 25 16:21:09 macmini kernel: [<ffffffff8045b130>] 
ip4_datagram_connect+0x230/0x2a0
Sep 25 16:21:09 macmini kernel: [<ffffffff8040fad2>] 
sockfd_lookup_light+0x22/0x90
Sep 25 16:21:09 macmini kernel: [<ffffffff80411049>] sys_sendto+0x119/0x180
Sep 25 16:21:09 macmini kernel: [<ffffffff80411195>] sys_connect+0xd5/0xe0
Sep 25 16:21:09 macmini kernel: [<ffffffff8020b73b>] 
system_call_after_swapgs+0x7b/0x80
Sep 25 16:21:09 macmini kernel:
Sep 25 16:21:09 macmini kernel: ---[ end trace 4bba0750c2376f51 ]---

bug report

[Todor Gyumyushev]

------------[ cut here ]------------
WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
Modules linked in: cdc_acm eth1394 vboxdrv isofs zlib_inflate ath5k 
aes_generic nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm 
acpi_cpufreq hci_usb rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss 
sunrpc exportfs fan ac battery microcode firmware_class loop usb_storage 
usbhid snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher 
snd_mixer_oss cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd 
rng_core cdrom ehci_hcd mac80211 thermal ohci1394 ieee1394 processor 
evdev thermal_sys tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore 
cfg80211 tpm_bios sky2 hwmon snd_page_alloc intel_agp button [last 
unloaded: ath5k]
Pid: 0, comm: swapper Tainted: G        W 2.6.26.5 #6

Call Trace:
 <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
 [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
 [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
 [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
 [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
 [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
 [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
 [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
 <EOI>  [<ffffffff8021c800>] lapic_next_event+0x0/0x10
 [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
 [<ffffffffa00564bc>] :processor:acpi_idle_enter_simple+0x1c5/0x235
 [<ffffffffa00564b2>] :processor:acpi_idle_enter_simple+0x1bb/0x235
 [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
 [<ffffffff803fbce7>] cpuidle_idle_call+0xd7/0x120
 [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
 [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
 [<ffffffff80209410>] default_idle+0x0/0x50
 [<ffffffff8020a720>] cpu_idle+0x60/0xd0

---[ end trace 05ba06d61030bbb9 ]---

Re: bug report

[Simon Holm Thøgersen]

ons, 24 09 2008 kl. 12:41 +0300, skrev Todor Gyumyushev:
> ------------[ cut here ]------------
> WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
> Modules linked in: cdc_acm eth1394 vboxdrv isofs zlib_inflate ath5k 
> aes_generic nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm 
> acpi_cpufreq hci_usb rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss 
> sunrpc exportfs fan ac battery microcode firmware_class loop usb_storage 
> usbhid snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher 
> snd_mixer_oss cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd 
> rng_core cdrom ehci_hcd mac80211 thermal ohci1394 ieee1394 processor 
> evdev thermal_sys tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore 
> cfg80211 tpm_bios sky2 hwmon snd_page_alloc intel_agp button [last 
> unloaded: ath5k]
> Pid: 0, comm: swapper Tainted: G        W 2.6.26.5 #6

This warning is not the first produced by your system, see the W flag in
the line above. Can you find an earlier warning in your dmesg/log? Or is
it similar to this one?

> Call Trace:
>  <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
>  [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
>  [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
>  [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
>  [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
>  [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
>  [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
>  [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
>  <EOI>  [<ffffffff8021c800>] lapic_next_event+0x0/0x10
>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>  [<ffffffffa00564bc>] :processor:acpi_idle_enter_simple+0x1c5/0x235
>  [<ffffffffa00564b2>] :processor:acpi_idle_enter_simple+0x1bb/0x235
>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>  [<ffffffff803fbce7>] cpuidle_idle_call+0xd7/0x120
>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>  [<ffffffff80209410>] default_idle+0x0/0x50
>  [<ffffffff8020a720>] cpu_idle+0x60/0xd0
> 
> ---[ end trace 05ba06d61030bbb9 ]---
> 


Simon Holm Thøgersen

Re: bug report

[Todor Gyumyushev]

Simon Holm Thøgersen wrote:
> ons, 24 09 2008 kl. 12:41 +0300, skrev Todor Gyumyushev:
>   
>> ------------[ cut here ]------------
>> WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
>> Modules linked in: cdc_acm eth1394 vboxdrv isofs zlib_inflate ath5k 
>> aes_generic nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm 
>> acpi_cpufreq hci_usb rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss 
>> sunrpc exportfs fan ac battery microcode firmware_class loop usb_storage 
>> usbhid snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher 
>> snd_mixer_oss cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd 
>> rng_core cdrom ehci_hcd mac80211 thermal ohci1394 ieee1394 processor 
>> evdev thermal_sys tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore 
>> cfg80211 tpm_bios sky2 hwmon snd_page_alloc intel_agp button [last 
>> unloaded: ath5k]
>> Pid: 0, comm: swapper Tainted: G        W 2.6.26.5 #6
>>     
>
> This warning is not the first produced by your system, see the W flag in
> the line above. Can you find an earlier warning in your dmesg/log? Or is
> it similar to this one?
>
>   
>> Call Trace:
>>  <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
>>  [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
>>  [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
>>  [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
>>  [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
>>  [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
>>  [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
>>  [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
>>  <EOI>  [<ffffffff8021c800>] lapic_next_event+0x0/0x10
>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>  [<ffffffffa00564bc>] :processor:acpi_idle_enter_simple+0x1c5/0x235
>>  [<ffffffffa00564b2>] :processor:acpi_idle_enter_simple+0x1bb/0x235
>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>  [<ffffffff803fbce7>] cpuidle_idle_call+0xd7/0x120
>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>  [<ffffffff80209410>] default_idle+0x0/0x50
>>  [<ffffffff8020a720>] cpu_idle+0x60/0xd0
>>
>> ---[ end trace 05ba06d61030bbb9 ]---
>>
>>     
>
>
> Simon Holm Thøgersen
>
>
>   
Hi there,

yes you are correct, I found another one earlier, initially I thought is 
the same but it is not.

Regards,
Todor


------------[ cut here ]------------
WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
Modules linked in: eth1394 vboxdrv isofs zlib_inflate ath5k aes_generic 
nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm acpi_cpufreq hci_usb 
rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs fan 
ac battery microcode firmware_class loop usb_storage usbhid 
snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher snd_mixer_oss 
cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd rng_core cdrom 
ehci_hcd mac80211 thermal ohci1394 ieee1394 processor evdev thermal_sys 
tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore cfg80211 tpm_bios 
sky2 hwmon snd_page_alloc intel_agp button [last unloaded: ath5k]
Pid: 13270, comm: npviewer.bin Not tainted 2.6.26.5 #6

Call Trace:
 <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
 [<ffffffff8032cf0b>] elv_next_request+0x12b/0x1f0
 [<ffffffff80252678>] getnstimeofday+0x48/0xc0
 [<ffffffff8024fe70>] ktime_get_ts+0x30/0x60
 [<ffffffff8024feac>] ktime_get+0xc/0x50
 [<ffffffff8022e58a>] hrtick_start_fair+0x12a/0x190
 [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
 [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
 [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
 [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
 [<ffffffff8023c44a>] __do_softirq+0x7a/0xf0
 [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
 [<ffffffff8020c8cc>] call_softirq+0x1c/0x30
 [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
 [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
 <EOI>
---[ end trace 05ba06d61030bbb9 ]---

Re: bug report

[Simon Holm Thøgersen]

[ CC'ing linux-ide mailing list and the people involved in commit
  56c819df (libata: update ATAPI overflow draining) that introduced the
  WARN_ON. ]

ons, 24 09 2008 kl. 20:55 +0300, skrev Todor Gyumyushev:
> Simon Holm Thøgersen wrote:
> > ons, 24 09 2008 kl. 12:41 +0300, skrev Todor Gyumyushev:
> >   
> >> ------------[ cut here ]------------
> >> WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
> >> Modules linked in: cdc_acm eth1394 vboxdrv isofs zlib_inflate ath5k 
> >> aes_generic nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm 
> >> acpi_cpufreq hci_usb rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss 
> >> sunrpc exportfs fan ac battery microcode firmware_class loop usb_storage 
> >> usbhid snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher 
> >> snd_mixer_oss cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd 
> >> rng_core cdrom ehci_hcd mac80211 thermal ohci1394 ieee1394 processor 
> >> evdev thermal_sys tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore 
> >> cfg80211 tpm_bios sky2 hwmon snd_page_alloc intel_agp button [last 
> >> unloaded: ath5k]
> >> Pid: 0, comm: swapper Tainted: G        W 2.6.26.5 #6
> >>     
> >
> > This warning is not the first produced by your system, see the W flag in
> > the line above. Can you find an earlier warning in your dmesg/log? Or is
> > it similar to this one?
> >
> >   
> >> Call Trace:
> >>  <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
> >>  [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
> >>  [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
> >>  [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
> >>  [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
> >>  [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
> >>  [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
> >>  [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
> >>  <EOI>  [<ffffffff8021c800>] lapic_next_event+0x0/0x10
> >>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
> >>  [<ffffffffa00564bc>] :processor:acpi_idle_enter_simple+0x1c5/0x235
> >>  [<ffffffffa00564b2>] :processor:acpi_idle_enter_simple+0x1bb/0x235
> >>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
> >>  [<ffffffff803fbce7>] cpuidle_idle_call+0xd7/0x120
> >>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
> >>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
> >>  [<ffffffff80209410>] default_idle+0x0/0x50
> >>  [<ffffffff8020a720>] cpu_idle+0x60/0xd0
> >>
> >> ---[ end trace 05ba06d61030bbb9 ]---
> >>
> >>     
> >
> >
> > Simon Holm Thøgersen
> >
> >
> >   
> Hi there,
> 
> yes you are correct, I found another one earlier, initially I thought is 
> the same but it is not.
> 
> Regards,
> Todor
> 
> 
> ------------[ cut here ]------------
> WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
> Modules linked in: eth1394 vboxdrv isofs zlib_inflate ath5k aes_generic 
> nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm acpi_cpufreq hci_usb 
> rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs fan 
> ac battery microcode firmware_class loop usb_storage usbhid 
> snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher snd_mixer_oss 
> cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd rng_core cdrom 
> ehci_hcd mac80211 thermal ohci1394 ieee1394 processor evdev thermal_sys 
> tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore cfg80211 tpm_bios 
> sky2 hwmon snd_page_alloc intel_agp button [last unloaded: ath5k]
> Pid: 13270, comm: npviewer.bin Not tainted 2.6.26.5 #6
> 
> Call Trace:
>  <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
>  [<ffffffff8032cf0b>] elv_next_request+0x12b/0x1f0
>  [<ffffffff80252678>] getnstimeofday+0x48/0xc0
>  [<ffffffff8024fe70>] ktime_get_ts+0x30/0x60
>  [<ffffffff8024feac>] ktime_get+0xc/0x50
>  [<ffffffff8022e58a>] hrtick_start_fair+0x12a/0x190
>  [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
>  [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
>  [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
>  [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
>  [<ffffffff8023c44a>] __do_softirq+0x7a/0xf0
>  [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
>  [<ffffffff8020c8cc>] call_softirq+0x1c/0x30
>  [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
>  [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
>  <EOI>
> ---[ end trace 05ba06d61030bbb9 ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: bug report

[Tejun Heo]

Simon Holm Thøgersen wrote:
> [ CC'ing linux-ide mailing list and the people involved in commit
>   56c819df (libata: update ATAPI overflow draining) that introduced the
>   WARN_ON. ]
> 
> ons, 24 09 2008 kl. 20:55 +0300, skrev Todor Gyumyushev:
>> Simon Holm Thøgersen wrote:
>>> ons, 24 09 2008 kl. 12:41 +0300, skrev Todor Gyumyushev:
>>>   
>>>> ------------[ cut here ]------------
>>>> WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
>>>> Modules linked in: cdc_acm eth1394 vboxdrv isofs zlib_inflate ath5k 
>>>> aes_generic nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm 
>>>> acpi_cpufreq hci_usb rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss 
>>>> sunrpc exportfs fan ac battery microcode firmware_class loop usb_storage 
>>>> usbhid snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher 
>>>> snd_mixer_oss cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd 
>>>> rng_core cdrom ehci_hcd mac80211 thermal ohci1394 ieee1394 processor 
>>>> evdev thermal_sys tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore 
>>>> cfg80211 tpm_bios sky2 hwmon snd_page_alloc intel_agp button [last 
>>>> unloaded: ath5k]
>>>> Pid: 0, comm: swapper Tainted: G        W 2.6.26.5 #6
>>>>     
>>> This warning is not the first produced by your system, see the W flag in
>>> the line above. Can you find an earlier warning in your dmesg/log? Or is
>>> it similar to this one?
>>>
>>>   
>>>> Call Trace:
>>>>  <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
>>>>  [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
>>>>  [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
>>>>  [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
>>>>  [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
>>>>  [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
>>>>  [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
>>>>  [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
>>>>  <EOI>  [<ffffffff8021c800>] lapic_next_event+0x0/0x10
>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>  [<ffffffffa00564bc>] :processor:acpi_idle_enter_simple+0x1c5/0x235
>>>>  [<ffffffffa00564b2>] :processor:acpi_idle_enter_simple+0x1bb/0x235
>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>  [<ffffffff803fbce7>] cpuidle_idle_call+0xd7/0x120
>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>  [<ffffffff80209410>] default_idle+0x0/0x50
>>>>  [<ffffffff8020a720>] cpu_idle+0x60/0xd0

Hmm... This shouldn't happen.  Can you please attach full kernel log
including the boot messages?

Thanks.

-- 
tejun

Re: bug report

[Todor Gyumyushev]

[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]

Tejun Heo wrote:
> Simon Holm Thøgersen wrote:
>   
>> [ CC'ing linux-ide mailing list and the people involved in commit
>>   56c819df (libata: update ATAPI overflow draining) that introduced the
>>   WARN_ON. ]
>>
>> ons, 24 09 2008 kl. 20:55 +0300, skrev Todor Gyumyushev:
>>     
>>> Simon Holm Thøgersen wrote:
>>>       
>>>> ons, 24 09 2008 kl. 12:41 +0300, skrev Todor Gyumyushev:
>>>>   
>>>>         
>>>>> ------------[ cut here ]------------
>>>>> WARNING: at drivers/ata/libata-sff.c:944 ata_sff_hsm_move+0x4a9/0x6a0()
>>>>> Modules linked in: cdc_acm eth1394 vboxdrv isofs zlib_inflate ath5k 
>>>>> aes_generic nls_utf8 nls_cp437 vfat fat nls_base i915 drm kvm 
>>>>> acpi_cpufreq hci_usb rfcomm l2cap pktcdvd nfsd lockd nfs_acl auth_rpcgss 
>>>>> sunrpc exportfs fan ac battery microcode firmware_class loop usb_storage 
>>>>> usbhid snd_hda_intel arc4 snd_pcm_oss sg ecb crypto_blkcipher 
>>>>> snd_mixer_oss cryptomgr snd_pcm snd_timer tpm_infineon sr_mod usblp snd 
>>>>> rng_core cdrom ehci_hcd mac80211 thermal ohci1394 ieee1394 processor 
>>>>> evdev thermal_sys tpm uhci_hcd iTCO_wdt iTCO_vendor_support soundcore 
>>>>> cfg80211 tpm_bios sky2 hwmon snd_page_alloc intel_agp button [last 
>>>>> unloaded: ath5k]
>>>>> Pid: 0, comm: swapper Tainted: G        W 2.6.26.5 #6
>>>>>     
>>>>>           
>>>> This warning is not the first produced by your system, see the W flag in
>>>> the line above. Can you find an earlier warning in your dmesg/log? Or is
>>>> it similar to this one?
>>>>
>>>>   
>>>>         
>>>>> Call Trace:
>>>>>  <IRQ>  [<ffffffff80236214>] warn_on_slowpath+0x64/0xc0
>>>>>  [<ffffffff803c9ec8>] ata_sff_data_xfer+0x98/0xc0
>>>>>  [<ffffffff803c96c9>] ata_sff_hsm_move+0x4a9/0x6a0
>>>>>  [<ffffffff803c9c13>] ata_sff_interrupt+0x1a3/0x2c0
>>>>>  [<ffffffff802748e4>] handle_IRQ_event+0x34/0x70
>>>>>  [<ffffffff80275e60>] handle_edge_irq+0xc0/0x160
>>>>>  [<ffffffff8020ebac>] do_IRQ+0x7c/0x100
>>>>>  [<ffffffff8020bc51>] ret_from_intr+0x0/0xa
>>>>>  <EOI>  [<ffffffff8021c800>] lapic_next_event+0x0/0x10
>>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>>  [<ffffffffa00564bc>] :processor:acpi_idle_enter_simple+0x1c5/0x235
>>>>>  [<ffffffffa00564b2>] :processor:acpi_idle_enter_simple+0x1bb/0x235
>>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>>  [<ffffffff803fbce7>] cpuidle_idle_call+0xd7/0x120
>>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>>  [<ffffffff803fbc10>] cpuidle_idle_call+0x0/0x120
>>>>>  [<ffffffff80209410>] default_idle+0x0/0x50
>>>>>  [<ffffffff8020a720>] cpu_idle+0x60/0xd0
>>>>>           
>
> Hmm... This shouldn't happen.  Can you please attach full kernel log
> including the boot messages?
>
> Thanks.
>
>   
Hi, here is attached the full kernel log.
It seems something is happening with ath5k module ?

Regards,
Todor


[-- Attachment #2: kernel.log.gz --]
[-- Type: application/gzip, Size: 33804 bytes --]

Re: bug report

[Tejun Heo]

Todor Gyumyushev wrote:
>> Hmm... This shouldn't happen.  Can you please attach full kernel log
>> including the boot messages?
>>
>> Thanks.
>>
>>   
> Hi, here is attached the full kernel log.
> It seems something is happening with ath5k module ?

Does the problem occur w/o ath5k?  I don't really see how ata_piix can
trigger the WARN_ON().

Thanks.

-- 
tejun

Bug report

[Jachin Spencer]

To Whom It May Concern:

	Installed the drivers, and firmware.  It worked fine at first, but 
after rebooting it stopped working.  After going to 
System->Administration->Network, I noticed I now have two wired 
connections, instead of one wireless one wired. I believe the problem is 
related to the known issue related to device naming rules.  I read your 
solution to the issue but as I am new to linux I am unsure where to make 
the changes.

System information:
Ubuntu 	8.04 (hardy)
GNOME 	2.22.2
Kernel	2.6.24-19-generic

CPU information:
Model name	AMD Turion(tm) 64 Mobile Technology ML-34

Hardware information:
Network Controller
	BCM4318 [AirForce One 54g] 802.11g
Ethernet controller
	RTK-8139/8139C/8139c+(rev 10)

If I have not provided all relevant information, please feel free to 
contact me at this email address.

,Jachin Spencer

Re: Bug report

[Pavel Roskin]

On Sat, 2008-07-26 at 08:17 -0700, Jachin Spencer wrote:
> To Whom It May Concern:
> 
> 	Installed the drivers, and firmware.  It worked fine at first, but 
> after rebooting it stopped working.  After going to 
> System->Administration->Network, I noticed I now have two wired 
> connections, instead of one wireless one wired.

Then it's a configuration issue, not a driver issue.  Please ask for
help in Ubuntu specific forums.

-- 
Regards,
Pavel Roskin

bug report

[Zsiros Attila]

Hy!

I have a problem.

http://www.cyberszeg.hu/log/kern.log
http://www.cyberszeg.hu/log/config-2.6.25.4
http://www.cyberszeg.hu/log/lspci.txt
http://www.cyberszeg.hu/log/ifconfig.txt

Best regards Zsirmo

Re: bug report

[Oliver Pinter]

Add Ingon and netdev to CC


On 6/6/08, Zsiros Attila <zsirmo@gmail.com> wrote:
> Hy!
>
> I have a problem.
>
> http://www.cyberszeg.hu/log/kern.log
> http://www.cyberszeg.hu/log/config-2.6.25.4
> http://www.cyberszeg.hu/log/lspci.txt
> http://www.cyberszeg.hu/log/ifconfig.txt
>
> Best regards Zsirmo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Thanks,
Oliver

Re: bug report

[Oliver Pinter]

Sorry, s/Ingon/Ingo/

On 6/7/08, Oliver Pinter <oliver.pntr@gmail.com> wrote:
> Add Ingon and netdev to CC
>
>
> On 6/6/08, Zsiros Attila <zsirmo@gmail.com> wrote:
>> Hy!
>>
>> I have a problem.
>>
>> http://www.cyberszeg.hu/log/kern.log
>> http://www.cyberszeg.hu/log/config-2.6.25.4
>> http://www.cyberszeg.hu/log/lspci.txt
>> http://www.cyberszeg.hu/log/ifconfig.txt
>>
>> Best regards Zsirmo
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
>
> --
> Thanks,
> Oliver
>


-- 
Thanks,
Oliver

Re: bug report

[Andrew Morton]

On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr@gmail.com> wrote:

> Add Ingon and netdev to CC
> 
> 
> On 6/6/08, Zsiros Attila <zsirmo@gmail.com> wrote:
> > Hy!
> >
> > I have a problem.
> >
> > http://www.cyberszeg.hu/log/kern.log
> > http://www.cyberszeg.hu/log/config-2.6.25.4
> > http://www.cyberszeg.hu/log/lspci.txt
> > http://www.cyberszeg.hu/log/ifconfig.txt
> >

: Jun  6 14:03:07 www kernel: [ 5897.660390] NETDEV WATCHDOG: eth0: transmit timed out
: Jun  6 14:03:07 www kernel: [ 5897.660398] tg3: eth0: transmit timed out, resetting
: Jun  6 14:03:07 www kernel: [ 5897.660432] tg3: DEBUG: MAC_TX_STATUS[0000001e] MAC_RX_STATUS[0000000e]
: Jun  6 14:03:07 www kernel: [ 5897.660454] tg3: DEBUG: RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
: Jun  6 14:03:07 www kernel: [ 5897.762983] tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2
: Jun  6 14:03:07 www kernel: [ 5897.864168] tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2
: Jun  6 14:03:07 www kernel: [ 5897.965619] tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2

That looks like a driver failure.

: Jun  6 14:03:07 www kernel: [ 5898.096689] tg3: eth0: Link is down.
: Jun  6 14:03:11 www kernel: [ 5901.633931] tg3: eth0: Link is up at 1000 Mbps, full duplex.
: Jun  6 14:03:11 www kernel: [ 5901.633937] tg3: eth0: Flow control is on for TX and on for RX.
: Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation failure. order:3, mode:0x4020
: Jun  6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan Not tainted 2.6.25.4 #1
: Jun  6 14:04:11 www kernel: [ 6464.556325] 
: Jun  6 14:04:11 www kernel: [ 6464.556326] Call Trace:
: Jun  6 14:04:11 www kernel: [ 6464.556329]  <IRQ>  [__alloc_pages+544/890] __alloc_pages+0x220/0x37a
: Jun  6 14:04:11 www kernel: [ 6464.556353]  [tcp_v4_do_rcv+186/504] tcp_v4_do_rcv+0xba/0x1f8
: Jun  6 14:04:11 www kernel: [ 6464.556359]  [ktime_get+12/98] ktime_get+0xc/0x62
: Jun  6 14:04:11 www kernel: [ 6464.556364]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun  6 14:04:11 www kernel: [ 6464.556370]  [__slab_alloc+330/1403] __slab_alloc+0x14a/0x57b
: Jun  6 14:04:11 www kernel: [ 6464.556374]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun  6 14:04:11 www kernel: [ 6464.556379]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun  6 14:04:11 www kernel: [ 6464.556384]  [__kmalloc_track_caller+185/190] __kmalloc_track_caller+0xb9/0xbe
: Jun  6 14:04:11 www kernel: [ 6464.556391]  [__alloc_skb+86/305] __alloc_skb+0x56/0x131
: Jun  6 14:04:11 www kernel: [ 6464.556395]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun  6 14:04:11 www kernel: [ 6464.556408]  [_end+128472975/2130444940] :tg3:tg3_alloc_rx_skb+0x8f/0x17e
: Jun  6 14:04:11 www kernel: [ 6464.556418]  [_end+128493403/2130444940] :tg3:tg3_poll+0x6e8/0x922
: Jun  6 14:04:11 www kernel: [ 6464.556426]  [net_rx_action+134/309] net_rx_action+0x86/0x135
: Jun  6 14:04:11 www kernel: [ 6464.556433]  [__do_softirq+102/212] __do_softirq+0x66/0xd4
: Jun  6 14:04:11 www kernel: [ 6464.556439]  [call_softirq+28/48] call_softirq+0x1c/0x30
: Jun  6 14:04:11 www kernel: [ 6464.556444]  [do_softirq+48/107] do_softirq+0x30/0x6b
: Jun  6 14:04:11 www kernel: [ 6464.556448]  [do_IRQ+114/212] do_IRQ+0x72/0xd4
: Jun  6 14:04:11 www kernel: [ 6464.556453]  [ret_from_intr+0/10] ret_from_intr+0x0/0xa

The driver is trying to do a 32 kbyte GFP_ATOMIC memory allocation. 
rofl, good luck with that.

But the netwoking code sould survive this.

<12 billion more page allocation failures>

Are you using jumbo frames or have you manually set the MTU to
something enormous?  Because 32k is a pretty crazy amount of memory for
the driver to be trying to allocate - it's going to fail all over the
place, as you have discovered.

Re: bug report

[Ilpo Järvinen]

...Added Brian Vowell.

On Fri, 6 Jun 2008, Andrew Morton wrote:

> On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr@gmail.com> wrote:
> 
> > Add Ingon and netdev to CC
> > 
> > 
> > On 6/6/08, Zsiros Attila <zsirmo@gmail.com> wrote:
> > > Hy!
> > >
> > > I have a problem.
> > >
> > > http://www.cyberszeg.hu/log/kern.log
> > > http://www.cyberszeg.hu/log/config-2.6.25.4
> > > http://www.cyberszeg.hu/log/lspci.txt
> > > http://www.cyberszeg.hu/log/ifconfig.txt
> > >
> 
> : Jun  6 14:03:07 www kernel: [ 5897.660390] NETDEV WATCHDOG: eth0: transmit timed out
> : Jun  6 14:03:07 www kernel: [ 5897.660398] tg3: eth0: transmit timed out, resetting
> : Jun  6 14:03:07 www kernel: [ 5897.660432] tg3: DEBUG: MAC_TX_STATUS[0000001e] MAC_RX_STATUS[0000000e]
> : Jun  6 14:03:07 www kernel: [ 5897.660454] tg3: DEBUG: RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
> : Jun  6 14:03:07 www kernel: [ 5897.762983] tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2
> : Jun  6 14:03:07 www kernel: [ 5897.864168] tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2
> : Jun  6 14:03:07 www kernel: [ 5897.965619] tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2
> 
> That looks like a driver failure.
> 
> : Jun  6 14:03:07 www kernel: [ 5898.096689] tg3: eth0: Link is down.
> : Jun  6 14:03:11 www kernel: [ 5901.633931] tg3: eth0: Link is up at 1000 Mbps, full duplex.
> : Jun  6 14:03:11 www kernel: [ 5901.633937] tg3: eth0: Flow control is on for TX and on for RX.
> : Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation failure. order:3, mode:0x4020
> : Jun  6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan Not tainted 2.6.25.4 #1
> : Jun  6 14:04:11 www kernel: [ 6464.556325] 
> : Jun  6 14:04:11 www kernel: [ 6464.556326] Call Trace:
> : Jun  6 14:04:11 www kernel: [ 6464.556329]  <IRQ>  [__alloc_pages+544/890] __alloc_pages+0x220/0x37a
> : Jun  6 14:04:11 www kernel: [ 6464.556353]  [tcp_v4_do_rcv+186/504] tcp_v4_do_rcv+0xba/0x1f8
> : Jun  6 14:04:11 www kernel: [ 6464.556359]  [ktime_get+12/98] ktime_get+0xc/0x62
> : Jun  6 14:04:11 www kernel: [ 6464.556364]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun  6 14:04:11 www kernel: [ 6464.556370]  [__slab_alloc+330/1403] __slab_alloc+0x14a/0x57b
> : Jun  6 14:04:11 www kernel: [ 6464.556374]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun  6 14:04:11 www kernel: [ 6464.556379]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun  6 14:04:11 www kernel: [ 6464.556384]  [__kmalloc_track_caller+185/190] __kmalloc_track_caller+0xb9/0xbe
> : Jun  6 14:04:11 www kernel: [ 6464.556391]  [__alloc_skb+86/305] __alloc_skb+0x56/0x131
> : Jun  6 14:04:11 www kernel: [ 6464.556395]  [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun  6 14:04:11 www kernel: [ 6464.556408]  [_end+128472975/2130444940] :tg3:tg3_alloc_rx_skb+0x8f/0x17e
> : Jun  6 14:04:11 www kernel: [ 6464.556418]  [_end+128493403/2130444940] :tg3:tg3_poll+0x6e8/0x922
> : Jun  6 14:04:11 www kernel: [ 6464.556426]  [net_rx_action+134/309] net_rx_action+0x86/0x135
> : Jun  6 14:04:11 www kernel: [ 6464.556433]  [__do_softirq+102/212] __do_softirq+0x66/0xd4
> : Jun  6 14:04:11 www kernel: [ 6464.556439]  [call_softirq+28/48] call_softirq+0x1c/0x30
> : Jun  6 14:04:11 www kernel: [ 6464.556444]  [do_softirq+48/107] do_softirq+0x30/0x6b
> : Jun  6 14:04:11 www kernel: [ 6464.556448]  [do_IRQ+114/212] do_IRQ+0x72/0xd4
> : Jun  6 14:04:11 www kernel: [ 6464.556453]  [ret_from_intr+0/10] ret_from_intr+0x0/0xa
> 
> The driver is trying to do a 32 kbyte GFP_ATOMIC memory allocation. 
> rofl, good luck with that.
> 
> But the netwoking code sould survive this.
> 
> <12 billion more page allocation failures>
> 
> Are you using jumbo frames or have you manually set the MTU to
> something enormous?  Because 32k is a pretty crazy amount of memory for
> the driver to be trying to allocate - it's going to fail all over the
> place, as you have discovered.

Same allocation failed problem (among an TCP issue that is nowadays 
fixed) was also reported by Brian Vowell:
  http://bugzilla.kernel.org/show_bug.cgi?id=10767


-- 
 i.

Re: bug report

[Oliver Pinter]

[snip]
Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
failure. order:3, mode:0x4020 <------------- this
Jun  6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan
Not tainted 2.6.25.4 #1
Jun  6 14:04:11 www kernel: [ 6464.556325]
Jun  6 14:04:11 www kernel: [ 6464.556326] Call Trace:
Jun  6 14:04:11 www kernel: [ 6464.556329]  <IRQ>
[__alloc_pages+544/890] __alloc_pages+0x220/0x37a
Jun  6 14:04:11 www kernel: [ 6464.556353]  [tcp_v4_do_rcv+186/504]
tcp_v4_do_rcv+0xba/0x1f8
[snip]

...

[snip]
Jun  6 14:04:11 www kernel: [ 6464.558231] Pid: 24139, comm: clamscan
Not tainted 2.6.25.4 #1
Jun  6 14:04:11 www kernel: [ 6464.558234]
Jun  6 14:04:11 www kernel: [ 6464.558235] Call Trace:
Jun  6 14:04:11 www kernel: [ 6464.558239]  <IRQ>
[__alloc_pages+544/890] __alloc_pages+0x220/0x37a
Jun  6 14:04:11 www kernel: [ 6464.558257]  [tcp_v4_do_rcv+186/504]
tcp_v4_do_rcv+0xba/0x1f8
Jun  6 14:04:11 www kernel: [ 6464.558263]
[apic_timer_interrupt+102/112] apic_timer_interrupt+0x6
[snip]

On 6/7/08, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> ...Added Brian Vowell.
>
> On Fri, 6 Jun 2008, Andrew Morton wrote:
>
>> On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr@gmail.com>
>> wrote:
>>
>> > Add Ingon and netdev to CC
>> >
>> >
>> > On 6/6/08, Zsiros Attila <zsirmo@gmail.com> wrote:
>> > > Hy!
>> > >
>> > > I have a problem.
>> > >
>> > > http://www.cyberszeg.hu/log/kern.log
>> > > http://www.cyberszeg.hu/log/config-2.6.25.4
>> > > http://www.cyberszeg.hu/log/lspci.txt
>> > > http://www.cyberszeg.hu/log/ifconfig.txt
>> > >
>>
>> : Jun  6 14:03:07 www kernel: [ 5897.660390] NETDEV WATCHDOG: eth0:
>> transmit timed out
>> : Jun  6 14:03:07 www kernel: [ 5897.660398] tg3: eth0: transmit timed
>> out, resetting
>> : Jun  6 14:03:07 www kernel: [ 5897.660432] tg3: DEBUG:
>> MAC_TX_STATUS[0000001e] MAC_RX_STATUS[0000000e]
>> : Jun  6 14:03:07 www kernel: [ 5897.660454] tg3: DEBUG:
>> RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
>> : Jun  6 14:03:07 www kernel: [ 5897.762983] tg3: tg3_stop_block timed
>> out, ofs=1800 enable_bit=2
>> : Jun  6 14:03:07 www kernel: [ 5897.864168] tg3: tg3_stop_block timed
>> out, ofs=c00 enable_bit=2
>> : Jun  6 14:03:07 www kernel: [ 5897.965619] tg3: tg3_stop_block timed
>> out, ofs=4800 enable_bit=2
>>
>> That looks like a driver failure.
>>
>> : Jun  6 14:03:07 www kernel: [ 5898.096689] tg3: eth0: Link is down.
>> : Jun  6 14:03:11 www kernel: [ 5901.633931] tg3: eth0: Link is up at 1000
>> Mbps, full duplex.
>> : Jun  6 14:03:11 www kernel: [ 5901.633937] tg3: eth0: Flow control is on
>> for TX and on for RX.
>> : Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>> failure. order:3, mode:0x4020
>> : Jun  6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan
>> Not tainted 2.6.25.4 #1
>> : Jun  6 14:04:11 www kernel: [ 6464.556325]
>> : Jun  6 14:04:11 www kernel: [ 6464.556326] Call Trace:
>> : Jun  6 14:04:11 www kernel: [ 6464.556329]  <IRQ>
>> [__alloc_pages+544/890] __alloc_pages+0x220/0x37a
>> : Jun  6 14:04:11 www kernel: [ 6464.556353]  [tcp_v4_do_rcv+186/504]
>> tcp_v4_do_rcv+0xba/0x1f8
>> : Jun  6 14:04:11 www kernel: [ 6464.556359]  [ktime_get+12/98]
>> ktime_get+0xc/0x62
>> : Jun  6 14:04:11 www kernel: [ 6464.556364]  [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun  6 14:04:11 www kernel: [ 6464.556370]  [__slab_alloc+330/1403]
>> __slab_alloc+0x14a/0x57b
>> : Jun  6 14:04:11 www kernel: [ 6464.556374]  [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun  6 14:04:11 www kernel: [ 6464.556379]  [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun  6 14:04:11 www kernel: [ 6464.556384]
>> [__kmalloc_track_caller+185/190] __kmalloc_track_caller+0xb9/0xbe
>> : Jun  6 14:04:11 www kernel: [ 6464.556391]  [__alloc_skb+86/305]
>> __alloc_skb+0x56/0x131
>> : Jun  6 14:04:11 www kernel: [ 6464.556395]  [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun  6 14:04:11 www kernel: [ 6464.556408]  [_end+128472975/2130444940]
>> :tg3:tg3_alloc_rx_skb+0x8f/0x17e
>> : Jun  6 14:04:11 www kernel: [ 6464.556418]  [_end+128493403/2130444940]
>> :tg3:tg3_poll+0x6e8/0x922
>> : Jun  6 14:04:11 www kernel: [ 6464.556426]  [net_rx_action+134/309]
>> net_rx_action+0x86/0x135
>> : Jun  6 14:04:11 www kernel: [ 6464.556433]  [__do_softirq+102/212]
>> __do_softirq+0x66/0xd4
>> : Jun  6 14:04:11 www kernel: [ 6464.556439]  [call_softirq+28/48]
>> call_softirq+0x1c/0x30
>> : Jun  6 14:04:11 www kernel: [ 6464.556444]  [do_softirq+48/107]
>> do_softirq+0x30/0x6b
>> : Jun  6 14:04:11 www kernel: [ 6464.556448]  [do_IRQ+114/212]
>> do_IRQ+0x72/0xd4
>> : Jun  6 14:04:11 www kernel: [ 6464.556453]  [ret_from_intr+0/10]
>> ret_from_intr+0x0/0xa
>>
>> The driver is trying to do a 32 kbyte GFP_ATOMIC memory allocation.
>> rofl, good luck with that.
>>
>> But the netwoking code sould survive this.
>>
>> <12 billion more page allocation failures>
>>
>> Are you using jumbo frames or have you manually set the MTU to
>> something enormous?  Because 32k is a pretty crazy amount of memory for
>> the driver to be trying to allocate - it's going to fail all over the
>> place, as you have discovered.
>
> Same allocation failed problem (among an TCP issue that is nowadays
> fixed) was also reported by Brian Vowell:
>   http://bugzilla.kernel.org/show_bug.cgi?id=10767
>
>
> --
>  i.
>


-- 
Thanks,
Oliver

Re: bug report

[Phil Oester]

On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
> [snip]
> Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
> failure. order:3, mode:0x4020 <------------- this

"Me too".  Lots of order 3 allocation failures on e1000 nics
since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
so unclear on when it began).

Phil

Jun  2 11:11:24 px01 kernel: swapper: page allocation failure. order:3, mode:0x4020
Jun  2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted 2.6.25.2-x86_64.1 #1
Jun  2 11:11:24 px01 kernel: 
Jun  2 11:11:24 px01 kernel: Call Trace:
Jun  2 11:11:24 px01 kernel:  <IRQ>  [<ffffffff8024ce51>] __alloc_pages+0x2dd/0x2f6
Jun  2 11:11:24 px01 kernel:  [<ffffffff8026578d>] __slab_alloc+0x16e/0x4f9
Jun  2 11:11:24 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
Jun  2 11:11:25 px01 kernel:  [<ffffffff802656d0>] __slab_alloc+0xb1/0x4f9
Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
Jun  2 11:11:25 px01 kernel:  [<ffffffff8026685d>] __kmalloc_track_caller+0x82/0xb8
Jun  2 11:11:25 px01 kernel:  [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
Jun  2 11:11:25 px01 kernel:  [<ffffffff80395261>] tcp_prune_queue+0x1ad/0x21e
Jun  2 11:11:25 px01 kernel:  [<ffffffff803954ba>] tcp_data_queue+0x1e8/0xbab
Jun  2 11:11:25 px01 kernel:  [<ffffffff803974e8>] tcp_rcv_established+0x64c/0x6fc
Jun  2 11:11:25 px01 kernel:  [<ffffffff8039c76f>] tcp_v4_do_rcv+0x2c/0x1b4
Jun  2 11:11:25 px01 kernel:  [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
Jun  2 11:11:25 px01 kernel:  [<ffffffff80384cdc>] ip_local_deliver_finish+0xf6/0x1b3
Jun  2 11:11:25 px01 kernel:  [<ffffffff80384bc3>] ip_rcv_finish+0x2bf/0x2e2
Jun  2 11:11:25 px01 kernel:  [<ffffffff8023ada3>] getnstimeofday+0x2f/0x83
Jun  2 11:11:25 px01 kernel:  [<ffffffff8036e6b2>] netif_receive_skb+0x1af/0x21b
Jun  2 11:11:25 px01 kernel:  [<ffffffff8032da6d>] e1000_clean_rx_irq+0x3f3/0x4e7

Re: bug report

[Oliver Pinter]

Hi!

Attila first use one other nic (rtl8169), and after one other (3com
BCM570). All NIC producted this error...
the full thread in Hungarian Unix Portal: http://hup.hu/node/56295

On 6/7/08, Phil Oester <kernel@linuxace.com> wrote:
> On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
>> [snip]
>> Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>> failure. order:3, mode:0x4020 <------------- this
>
> "Me too".  Lots of order 3 allocation failures on e1000 nics
> since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
> so unclear on when it began).
>
> Phil
>
> Jun  2 11:11:24 px01 kernel: swapper: page allocation failure. order:3,
> mode:0x4020
> Jun  2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted
> 2.6.25.2-x86_64.1 #1
> Jun  2 11:11:24 px01 kernel:
> Jun  2 11:11:24 px01 kernel: Call Trace:
> Jun  2 11:11:24 px01 kernel:  <IRQ>  [<ffffffff8024ce51>]
> __alloc_pages+0x2dd/0x2f6
> Jun  2 11:11:24 px01 kernel:  [<ffffffff8026578d>] __slab_alloc+0x16e/0x4f9
> Jun  2 11:11:24 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
> Jun  2 11:11:25 px01 kernel:  [<ffffffff802656d0>] __slab_alloc+0xb1/0x4f9
> Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
> Jun  2 11:11:25 px01 kernel:  [<ffffffff8026685d>]
> __kmalloc_track_caller+0x82/0xb8
> Jun  2 11:11:25 px01 kernel:  [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
> Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
> Jun  2 11:11:25 px01 kernel:  [<ffffffff80395261>]
> tcp_prune_queue+0x1ad/0x21e
> Jun  2 11:11:25 px01 kernel:  [<ffffffff803954ba>]
> tcp_data_queue+0x1e8/0xbab
> Jun  2 11:11:25 px01 kernel:  [<ffffffff803974e8>]
> tcp_rcv_established+0x64c/0x6fc
> Jun  2 11:11:25 px01 kernel:  [<ffffffff8039c76f>] tcp_v4_do_rcv+0x2c/0x1b4
> Jun  2 11:11:25 px01 kernel:  [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
> Jun  2 11:11:25 px01 kernel:  [<ffffffff80384cdc>]
> ip_local_deliver_finish+0xf6/0x1b3
> Jun  2 11:11:25 px01 kernel:  [<ffffffff80384bc3>] ip_rcv_finish+0x2bf/0x2e2
> Jun  2 11:11:25 px01 kernel:  [<ffffffff8023ada3>] getnstimeofday+0x2f/0x83
> Jun  2 11:11:25 px01 kernel:  [<ffffffff8036e6b2>]
> netif_receive_skb+0x1af/0x21b
> Jun  2 11:11:25 px01 kernel:  [<ffffffff8032da6d>]
> e1000_clean_rx_irq+0x3f3/0x4e7
>
>


-- 
Thanks,
Oliver

Re: bug report

[Zsiros Attila]

Hy!

Newer log
http://www.cyberszeg.hu/log/kern2.log

Zsirmo

Oliver Pinter írta:
> Hi!
>
> Attila first use one other nic (rtl8169), and after one other (3com
> BCM570). All NIC producted this error...
> the full thread in Hungarian Unix Portal: http://hup.hu/node/56295
>
> On 6/7/08, Phil Oester <kernel@linuxace.com> wrote:
>   
>> On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
>>     
>>> [snip]
>>> Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>>> failure. order:3, mode:0x4020 <------------- this
>>>       
>> "Me too".  Lots of order 3 allocation failures on e1000 nics
>> since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
>> so unclear on when it began).
>>
>> Phil
>>
>> Jun  2 11:11:24 px01 kernel: swapper: page allocation failure. order:3,
>> mode:0x4020
>> Jun  2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted
>> 2.6.25.2-x86_64.1 #1
>> Jun  2 11:11:24 px01 kernel:
>> Jun  2 11:11:24 px01 kernel: Call Trace:
>> Jun  2 11:11:24 px01 kernel:  <IRQ>  [<ffffffff8024ce51>]
>> __alloc_pages+0x2dd/0x2f6
>> Jun  2 11:11:24 px01 kernel:  [<ffffffff8026578d>] __slab_alloc+0x16e/0x4f9
>> Jun  2 11:11:24 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff802656d0>] __slab_alloc+0xb1/0x4f9
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8026685d>]
>> __kmalloc_track_caller+0x82/0xb8
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>] tcp_collapse+0x164/0x394
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80395261>]
>> tcp_prune_queue+0x1ad/0x21e
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff803954ba>]
>> tcp_data_queue+0x1e8/0xbab
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff803974e8>]
>> tcp_rcv_established+0x64c/0x6fc
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8039c76f>] tcp_v4_do_rcv+0x2c/0x1b4
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80384cdc>]
>> ip_local_deliver_finish+0xf6/0x1b3
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80384bc3>] ip_rcv_finish+0x2bf/0x2e2
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8023ada3>] getnstimeofday+0x2f/0x83
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8036e6b2>]
>> netif_receive_skb+0x1af/0x21b
>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8032da6d>]
>> e1000_clean_rx_irq+0x3f3/0x4e7
>>
>>
>>     
>
>
>   

Re: bug report

[Oliver Pinter]

an other case, but with nvidia

http://frugalware.org/paste/2639

On 6/8/08, Zsiros Attila <zsirmo@zsirmo.hu> wrote:
> Hy!
>
> Newer log
> http://www.cyberszeg.hu/log/kern2.log
>
> Zsirmo
>
> Oliver Pinter írta:
>> Hi!
>>
>> Attila first use one other nic (rtl8169), and after one other (3com
>> BCM570). All NIC producted this error...
>> the full thread in Hungarian Unix Portal: http://hup.hu/node/56295
>>
>> On 6/7/08, Phil Oester <kernel@linuxace.com> wrote:
>>
>>> On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
>>>
>>>> [snip]
>>>> Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>>>> failure. order:3, mode:0x4020 <------------- this
>>>>
>>> "Me too".  Lots of order 3 allocation failures on e1000 nics
>>> since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
>>> so unclear on when it began).
>>>
>>> Phil
>>>
>>> Jun  2 11:11:24 px01 kernel: swapper: page allocation failure. order:3,
>>> mode:0x4020
>>> Jun  2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted
>>> 2.6.25.2-x86_64.1 #1
>>> Jun  2 11:11:24 px01 kernel:
>>> Jun  2 11:11:24 px01 kernel: Call Trace:
>>> Jun  2 11:11:24 px01 kernel:  <IRQ>  [<ffffffff8024ce51>]
>>> __alloc_pages+0x2dd/0x2f6
>>> Jun  2 11:11:24 px01 kernel:  [<ffffffff8026578d>]
>>> __slab_alloc+0x16e/0x4f9
>>> Jun  2 11:11:24 px01 kernel:  [<ffffffff80394e84>]
>>> tcp_collapse+0x164/0x394
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff802656d0>]
>>> __slab_alloc+0xb1/0x4f9
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>]
>>> tcp_collapse+0x164/0x394
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8026685d>]
>>> __kmalloc_track_caller+0x82/0xb8
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80394e84>]
>>> tcp_collapse+0x164/0x394
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80395261>]
>>> tcp_prune_queue+0x1ad/0x21e
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff803954ba>]
>>> tcp_data_queue+0x1e8/0xbab
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff803974e8>]
>>> tcp_rcv_established+0x64c/0x6fc
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8039c76f>]
>>> tcp_v4_do_rcv+0x2c/0x1b4
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80384cdc>]
>>> ip_local_deliver_finish+0xf6/0x1b3
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff80384bc3>]
>>> ip_rcv_finish+0x2bf/0x2e2
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8023ada3>]
>>> getnstimeofday+0x2f/0x83
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8036e6b2>]
>>> netif_receive_skb+0x1af/0x21b
>>> Jun  2 11:11:25 px01 kernel:  [<ffffffff8032da6d>]
>>> e1000_clean_rx_irq+0x3f3/0x4e7
>>>
>>>
>>>
>>
>>
>>
>
>


-- 
Thanks,
Oliver

Bug Report

[Mark Goodall]

Not sure what caused this bug, how much more information do you need?

        - 18:01:15: check for inodes claiming duplicate blocks - 198528 of
198528 inodes done
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem starting at / ...
corrupt dinode 25809974, extent total = 16, nblocks = 0.  This is a bug.
Please report it to xfs@oss.sgi.com.
cache_node_purge: refcount was 1, not zero (node=0x8d65fd0)
couldn't map inode 25809974, err = 117
entry "gobo_3.3-6_i386.deb" in shortform directory inode 1770978822 points
to free inode 1770978825
would junk entry "gobo_3.3-6_i386.deb"
        - 18:01:48: traversing filesystem - 32 of 32 allocation groups done
        - traversal finished ...
        - traversing all unattached subtrees ...
Segmentation fault (core dumped)

OS: Ubuntu Linux mserve 2.6.20-16-386 #2 Fri Aug 31 00:51:58 UTC 2007 i686
GNU/Linux
fully patched from official repositories


[[HTML alternate version deleted]]

Re: Bug Report

[Barry Naujok]

On Fri, 07 Sep 2007 03:05:29 +1000, Mark Goodall <mark.goodall@gmail.com>  
wrote:

> Not sure what caused this bug, how much more information do you need?

Version number of xfs_repair. Also, if possible, a zipped metadump image
(need xfsprogs 2.9.0 or later) to fix any xfs_repair bugs.

Regards,
Barry.

>         - 18:01:15: check for inodes claiming duplicate blocks - 198528  
> of
> 198528 inodes done
> No modify flag set, skipping phase 5
> Phase 6 - check inode connectivity...
>         - traversing filesystem starting at / ...
> corrupt dinode 25809974, extent total = 16, nblocks = 0.  This is a bug.
> Please report it to xfs@oss.sgi.com.
> cache_node_purge: refcount was 1, not zero (node=0x8d65fd0)
> couldn't map inode 25809974, err = 117
> entry "gobo_3.3-6_i386.deb" in shortform directory inode 1770978822  
> points
> to free inode 1770978825
> would junk entry "gobo_3.3-6_i386.deb"
>         - 18:01:48: traversing filesystem - 32 of 32 allocation groups  
> done
>         - traversal finished ...
>         - traversing all unattached subtrees ...
> Segmentation fault (core dumped)
>
> OS: Ubuntu Linux mserve 2.6.20-16-386 #2 Fri Aug 31 00:51:58 UTC 2007  
> i686
> GNU/Linux
> fully patched from official repositories
>
>
> [[HTML alternate version deleted]]
>
>

Re: Bug Report

[Barry Naujok]

On Fri, 07 Sep 2007 03:05:29 +1000, Mark Goodall <mark.goodall@gmail.com>  
wrote:

> Not sure what caused this bug, how much more information do you need?
>
>         - 18:01:15: check for inodes claiming duplicate blocks - 198528  
> of
> 198528 inodes done
> No modify flag set, skipping phase 5
> Phase 6 - check inode connectivity...
>         - traversing filesystem starting at / ...
> corrupt dinode 25809974, extent total = 16, nblocks = 0.  This is a bug.
> Please report it to xfs@oss.sgi.com.
> cache_node_purge: refcount was 1, not zero (node=0x8d65fd0)
> couldn't map inode 25809974, err = 117
> entry "gobo_3.3-6_i386.deb" in shortform directory inode 1770978822  
> points
> to free inode 1770978825
> would junk entry "gobo_3.3-6_i386.deb"
>         - 18:01:48: traversing filesystem - 32 of 32 allocation groups  
> done
>         - traversal finished ...
>         - traversing all unattached subtrees ...
> Segmentation fault (core dumped)
>
> OS: Ubuntu Linux mserve 2.6.20-16-386 #2 Fri Aug 31 00:51:58 UTC 2007  
> i686
> GNU/Linux
> fully patched from official repositories

Latest xfsprogs 2.9.4 doesn't segfault anymore in Phase 6.

The "corrupt dinode..." error is a symptom of running
xfs_repair in -n mode where Phase 3 would have fixed the
offending inode up:

-n mode:
   bad attribute format 0 in inode 25809974, would reset value
   bad anextents 16 for inode 25809974, would reset to 0

repair mode:
   bad attribute format 0 in inode 25809974, resetting value
   correcting anextents for inode 25809974, was 16 - counted 0

Regards,
Barry.

BUG report

[Antonio Mignolli]

I'm on a Slackware with kernel 2.6.17.3 obtained by applying patch-2.6.17.3
to kernel 2.6.17.
I plugged a Pinnacle pctv 50e USB tv card.
It works correctly, I was trying it.
After a while, I disconnected it and after very few seconds
I plugged an external USB hard drive.
For a couple of minutes, USB hub seemed to be not working.
No messages on dmesg indicating a new device (usually /dev/sda,
I have all the modules for that.)
After about two minutes, the USB hub woke up (/dev/sda created, USB
mouse working)
and on syslog and on every terminal on my
desktop appeared some messages.

TERMINAL MESSAGES:

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: Oops: 0002 [#1]

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: PREEMPT

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: CPU:    0

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: EIP is at __fput+0xab/0x140

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: eax: 00000007   ebx: d613c000   ecx: d61cc030   edx: c01ebbf7

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: esi: d3ba2780   edi: d9548184   ebp: d94ede14   esp: d613df6c

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: ds: 007b   es: 007b   ss: 0068

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: Process firefox-bin (pid: 5500, threadinfo=d613c000
task=d61cc030)

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: Stack: df7c4f40 d3ba2780 df68c5c0 00000000 d613c000
c0147fda d3ba2780 df68c5c0

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel:        d3ba2780 df68c5c0 d613c000 df68c5c0 d3ba2780
c014803c d3ba2780 df68c5c0

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel:        00000030 00000002 09557fb0 c01025d7 00000030
00000000 b68c7600 00000002

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: Call Trace:

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel:  <c0147fda> filp_close+0x4c/0x55  <c014803c> sys_close+0x59/0x7c

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel:  <c01025d7> syscall_call+0x7/0xb

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: Code: 38 58 5a 8b 87 f4 00 00 00 85 c0 74 07 50 e8 6a
6e 00 00 58 8b 46 10 85 c0
 74 35 8b 00 85 c0 74 2f bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 88 00 01
00 00 83 38 02 75 0b 8b 80
 88 01 00 00 e8 08 67 fc

Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
slacky kernel: EIP: [<c01493c9>] __fput+0xab/0x140 SS:ESP 0068:d613df6c


SYSLOG MESSAGES:

Jul  5 23:38:39 slacky kernel: BUG: unable to handle kernel NULL
pointer dereference at virtual
 address 00000107
Jul  5 23:38:39 slacky kernel:  printing eip:
Jul  5 23:38:39 slacky kernel: c01493c9
Jul  5 23:38:39 slacky kernel: *pde = 00000000
Jul  5 23:38:39 slacky kernel: Oops: 0002 [#1]
Jul  5 23:38:39 slacky kernel: PREEMPT
Jul  5 23:38:39 slacky kernel: Modules linked in: vfat fat snd_pcm_oss
snd_mixer_oss snd_usb_au
dio snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep tda9887 tuner
saa7115 em28xx compat_ioctl3
2 v4l1_compat v4l2_common ir_common videodev tveeprom i2c_core eth1394
snd_intel8x0 snd_intel8x
0m snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc
yenta_socket rsrc_nonstatic
 pcmcia_core ohci1394 b44 joydev fuse evdev
Jul  5 23:38:39 slacky kernel: CPU:    0
Jul  5 23:38:39 slacky kernel: EIP:    0060:[<c01493c9>]    Not tainted VLI
Jul  5 23:38:39 slacky kernel: EFLAGS: 00010202   (2.6.17.3 #7)
Jul  5 23:38:39 slacky kernel: EIP is at __fput+0xab/0x140
Jul  5 23:38:39 slacky kernel: eax: 00000007   ebx: d613c000   ecx:
d61cc030   edx: c01ebbf7
Jul  5 23:38:39 slacky kernel: esi: d3ba2780   edi: d9548184   ebp:
d94ede14   esp: d613df6c
Jul  5 23:38:39 slacky kernel: ds: 007b   es: 007b   ss: 0068
Jul  5 23:38:39 slacky kernel: Process firefox-bin (pid: 5500,
threadinfo=d613c000 task=d61cc03
0)
Jul  5 23:38:39 slacky kernel: Stack: df7c4f40 d3ba2780 df68c5c0
00000000 d613c000 c0147fda d3b
a2780 df68c5c0
Jul  5 23:38:39 slacky kernel:        d3ba2780 df68c5c0 d613c000
df68c5c0 d3ba2780 c014803c d3b
a2780 df68c5c0
Jul  5 23:38:39 slacky kernel:        00000030 00000002 09557fb0
c01025d7 00000030 00000000 b68
c7600 00000002
Jul  5 23:38:39 slacky kernel: Call Trace:
Jul  5 23:38:39 slacky kernel:  <c0147fda> filp_close+0x4c/0x55
<c014803c> sys_close+0x59/0x7c
Jul  5 23:38:39 slacky kernel:  <c01025d7> syscall_call+0x7/0xb
Jul  5 23:38:39 slacky kernel: Code: 38 58 5a 8b 87 f4 00 00 00 85 c0
74 07 50 e8 6a 6e 00 00 5
8 8b 46 10 85 c0 74 35 8b 00 85 c0 74 2f bb 00 e0 ff ff 21 e3 ff 43 14
<ff> 88 00 01 00 00 83 3
8 02 75 0b 8b 80 88 01 00 00 e8 08 67 fc
Jul  5 23:38:39 slacky kernel: EIP: [<c01493c9>] __fput+0xab/0x140
SS:ESP 0068:d613df6c
Jul  5 23:38:39 slacky kernel:  <6>note: firefox-bin[5500] exited with
preempt_count 1
Jul  5 23:38:39 slacky kernel: hub 1-0:1.0: over-current change on port 2
Jul  5 23:38:39 slacky kernel: hub 2-0:1.0: over-current change on port 1
Jul  5 23:38:39 slacky kernel: hub 2-0:1.0: over-current change on port 2
Jul  5 23:38:40 slacky kernel: hub 1-0:1.0: over-current change on port 1
Jul  5 23:40:37 slacky kernel: hub 1-0:1.0: over-current change on port 1
Jul  5 23:40:37 slacky kernel: hub 2-0:1.0: over-current change on port 1
Jul  5 23:40:44 slacky kernel: sda: assuming drive cache: write through
Jul  5 23:40:44 slacky kernel: sda: assuming drive cache: write through



Hope it helps.
Bye.

Re: BUG report

[Markus Rechberger]

Hi,

this very likely has nothing to do with the TV tuner.
There's an issue if you access an usbaudio device and unplug it the
system might lock up the keyboard.
Also mozilla caused that issue on your side, so I only know that dumb
written mozilla plugins directly access /dev/dsp* /dev/mixer* devices
and don't release them (especially the mixer one)
This causes problems in the alsa framework...
I think the pinnacle 50e supports digital audio -> a part of that
device acts as a usb audio device.
You could also blame the firefox guys to document their plugin
interface once in this century rather than adding more new bugged
code... (I made some experience with that part a while ago)

Markus

On 7/9/06, Antonio Mignolli <antoniomignolli@gmail.com> wrote:
> I'm on a Slackware with kernel 2.6.17.3 obtained by applying patch-2.6.17.3
> to kernel 2.6.17.
> I plugged a Pinnacle pctv 50e USB tv card.
> It works correctly, I was trying it.
> After a while, I disconnected it and after very few seconds
> I plugged an external USB hard drive.
> For a couple of minutes, USB hub seemed to be not working.
> No messages on dmesg indicating a new device (usually /dev/sda,
> I have all the modules for that.)
> After about two minutes, the USB hub woke up (/dev/sda created, USB
> mouse working)
> and on syslog and on every terminal on my
> desktop appeared some messages.
>
> TERMINAL MESSAGES:
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: Oops: 0002 [#1]
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: PREEMPT
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: CPU:    0
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: EIP is at __fput+0xab/0x140
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: eax: 00000007   ebx: d613c000   ecx: d61cc030   edx: c01ebbf7
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: esi: d3ba2780   edi: d9548184   ebp: d94ede14   esp: d613df6c
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: ds: 007b   es: 007b   ss: 0068
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: Process firefox-bin (pid: 5500, threadinfo=d613c000
> task=d61cc030)
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: Stack: df7c4f40 d3ba2780 df68c5c0 00000000 d613c000
> c0147fda d3ba2780 df68c5c0
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel:        d3ba2780 df68c5c0 d613c000 df68c5c0 d3ba2780
> c014803c d3ba2780 df68c5c0
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel:        00000030 00000002 09557fb0 c01025d7 00000030
> 00000000 b68c7600 00000002
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: Call Trace:
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel:  <c0147fda> filp_close+0x4c/0x55  <c014803c> sys_close+0x59/0x7c
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel:  <c01025d7> syscall_call+0x7/0xb
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: Code: 38 58 5a 8b 87 f4 00 00 00 85 c0 74 07 50 e8 6a
> 6e 00 00 58 8b 46 10 85 c0
>  74 35 8b 00 85 c0 74 2f bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 88 00 01
> 00 00 83 38 02 75 0b 8b 80
>  88 01 00 00 e8 08 67 fc
>
> Message from syslogd@slacky at Wed Jul  5 23:38:39 2006 ...
> slacky kernel: EIP: [<c01493c9>] __fput+0xab/0x140 SS:ESP 0068:d613df6c
>
>
> SYSLOG MESSAGES:
>
> Jul  5 23:38:39 slacky kernel: BUG: unable to handle kernel NULL
> pointer dereference at virtual
>  address 00000107
> Jul  5 23:38:39 slacky kernel:  printing eip:
> Jul  5 23:38:39 slacky kernel: c01493c9
> Jul  5 23:38:39 slacky kernel: *pde = 00000000
> Jul  5 23:38:39 slacky kernel: Oops: 0002 [#1]
> Jul  5 23:38:39 slacky kernel: PREEMPT
> Jul  5 23:38:39 slacky kernel: Modules linked in: vfat fat snd_pcm_oss
> snd_mixer_oss snd_usb_au
> dio snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep tda9887 tuner
> saa7115 em28xx compat_ioctl3
> 2 v4l1_compat v4l2_common ir_common videodev tveeprom i2c_core eth1394
> snd_intel8x0 snd_intel8x
> 0m snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc
> yenta_socket rsrc_nonstatic
>  pcmcia_core ohci1394 b44 joydev fuse evdev
> Jul  5 23:38:39 slacky kernel: CPU:    0
> Jul  5 23:38:39 slacky kernel: EIP:    0060:[<c01493c9>]    Not tainted VLI
> Jul  5 23:38:39 slacky kernel: EFLAGS: 00010202   (2.6.17.3 #7)
> Jul  5 23:38:39 slacky kernel: EIP is at __fput+0xab/0x140
> Jul  5 23:38:39 slacky kernel: eax: 00000007   ebx: d613c000   ecx:
> d61cc030   edx: c01ebbf7
> Jul  5 23:38:39 slacky kernel: esi: d3ba2780   edi: d9548184   ebp:
> d94ede14   esp: d613df6c
> Jul  5 23:38:39 slacky kernel: ds: 007b   es: 007b   ss: 0068
> Jul  5 23:38:39 slacky kernel: Process firefox-bin (pid: 5500,
> threadinfo=d613c000 task=d61cc03
> 0)
> Jul  5 23:38:39 slacky kernel: Stack: df7c4f40 d3ba2780 df68c5c0
> 00000000 d613c000 c0147fda d3b
> a2780 df68c5c0
> Jul  5 23:38:39 slacky kernel:        d3ba2780 df68c5c0 d613c000
> df68c5c0 d3ba2780 c014803c d3b
> a2780 df68c5c0
> Jul  5 23:38:39 slacky kernel:        00000030 00000002 09557fb0
> c01025d7 00000030 00000000 b68
> c7600 00000002
> Jul  5 23:38:39 slacky kernel: Call Trace:
> Jul  5 23:38:39 slacky kernel:  <c0147fda> filp_close+0x4c/0x55
> <c014803c> sys_close+0x59/0x7c
> Jul  5 23:38:39 slacky kernel:  <c01025d7> syscall_call+0x7/0xb
> Jul  5 23:38:39 slacky kernel: Code: 38 58 5a 8b 87 f4 00 00 00 85 c0
> 74 07 50 e8 6a 6e 00 00 5
> 8 8b 46 10 85 c0 74 35 8b 00 85 c0 74 2f bb 00 e0 ff ff 21 e3 ff 43 14
> <ff> 88 00 01 00 00 83 3
> 8 02 75 0b 8b 80 88 01 00 00 e8 08 67 fc
> Jul  5 23:38:39 slacky kernel: EIP: [<c01493c9>] __fput+0xab/0x140
> SS:ESP 0068:d613df6c
> Jul  5 23:38:39 slacky kernel:  <6>note: firefox-bin[5500] exited with
> preempt_count 1
> Jul  5 23:38:39 slacky kernel: hub 1-0:1.0: over-current change on port 2
> Jul  5 23:38:39 slacky kernel: hub 2-0:1.0: over-current change on port 1
> Jul  5 23:38:39 slacky kernel: hub 2-0:1.0: over-current change on port 2
> Jul  5 23:38:40 slacky kernel: hub 1-0:1.0: over-current change on port 1
> Jul  5 23:40:37 slacky kernel: hub 1-0:1.0: over-current change on port 1
> Jul  5 23:40:37 slacky kernel: hub 2-0:1.0: over-current change on port 1
> Jul  5 23:40:44 slacky kernel: sda: assuming drive cache: write through
> Jul  5 23:40:44 slacky kernel: sda: assuming drive cache: write through
>
>
>
> Hope it helps.
> Bye.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Markus Rechberger

RE: bug report

[Ian Pratt]

> 1. Time stopped (Build 7398)
> 
> When starting a domU the system time (in dom0) stopps for a 
> few seconds and sometimes forever. With disabled Hyperthreading or
> maxcpus=1 all works fine.

Can anyone repro this?
Are you using the -xen kernel config?

Ian

Re: bug report

[David F Barrera]

Ian,

I replied to that original message indicating that I did not see the 
problem anymore, since aroung changeset 7396. Stephan replied that he 
had been wrong, working on an older build (reply copied below).


David

Hi David


>>> > 1. Time stopped (Build 7398)
>>    
>>
>> That's odd. I have not seen this problem since Monday, using 
>> changesets
>> 7396 and up. 
>  
>

You have right. As i've tested it, it was on an older build.
7398 i've installed just later. sorry, my fault.

Stephan



Ian Pratt wrote:

>>1. Time stopped (Build 7398)
>>
>>When starting a domU the system time (in dom0) stopps for a 
>>few seconds and sometimes forever. With disabled Hyperthreading or
>>maxcpus=1 all works fine.
>>    
>>
>
>Can anyone repro this?
>Are you using the -xen kernel config?
>
>Ian
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: bug report

[Stephan Böni]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

Hi David

> > 1. Time stopped (Build 7398)
> That's odd. I have not seen this problem since Monday, using 
> changesets
> 7396 and up. 

You have right. As i've tested it, it was on an older build.
7398 i've installed just later. sorry, my fault.

Stephan

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

bug report

[Stephan Böni]

In the last days i've found two heavy bugs. Is someone working on it?

1. Time stopped (Build 7398)

When starting a domU the system time (in dom0) stopps for a few
seconds and sometimes forever. With disabled Hyperthreading or
maxcpus=1 all works fine.

2. Mounting lots of drives (Build 7398)

Some device nodes (/dev/hd*) are missing in a domU. I can find
in /var/log/messages an interesting thing. For all 16 configured
devices i've found an entry like:
"...xen1 logger: /etc/xen/scripts/block: bind ..."
But only for 9 devices i've found an entry like:
"...xen1 logger: /etc/xen/scripts/block: Writing backend/vbd/1/..."
On the second try to start the domU i've found 12 "Writing backend"
entries and on the third try 10 of them.
If the root device (/dev/hda1) is one of them, i cannot logon
to my domU. The missing /dev/hd*'s are these ones, which haven't
a "Writing backend" entry in the /var/log/messages file.
Interesting thing: I had never this problem with file devices, only
with lvm devices.

Stephan

Re: bug report

[David F Barrera]

On Thu, 2005-10-20 at 14:47 +0200, Stephan Böni wrote:
> In the last days i've found two heavy bugs. Is someone working on it?
> 
> 1. Time stopped (Build 7398)
That's odd. I have not seen this problem since Monday, using changesets
7396 and up. 
> 
> When starting a domU the system time (in dom0) stopps for a few
> seconds and sometimes forever. With disabled Hyperthreading or
> maxcpus=1 all works fine.
> 
> 2. Mounting lots of drives (Build 7398)
> 
> Some device nodes (/dev/hd*) are missing in a domU. I can find
> in /var/log/messages an interesting thing. For all 16 configured
> devices i've found an entry like:
> "...xen1 logger: /etc/xen/scripts/block: bind ..."
> But only for 9 devices i've found an entry like:
> "...xen1 logger: /etc/xen/scripts/block: Writing backend/vbd/1/..."
> On the second try to start the domU i've found 12 "Writing backend"
> entries and on the third try 10 of them.
> If the root device (/dev/hda1) is one of them, i cannot logon
> to my domU. The missing /dev/hd*'s are these ones, which haven't
> a "Writing backend" entry in the /var/log/messages file.
> Interesting thing: I had never this problem with file devices, only
> with lvm devices.
> 
> Stephan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
                                                        Euripides

bug report

[Jerry DeLisle]

Does the following need to be reported?  From dmesg:

     ACPI-1138: *** Error: Method execution failed [\MCTH] (Node 
def2d540), AE_AML_BUFFER_LIMIT
     ACPI-1138: *** Error: Method execution failed [\OSFL] (Node 
def2d4c0), AE_AML_BUFFER_LIMIT
     ACPI-1138: *** Error: Method execution failed [\_SB_.SYSM._CRS] 
(Node dee81ec0), AE_AML_BUFFER_LIMIT
     ACPI-0158: *** Error: Method execution failed [\_SB_.SYSM._CRS] 
(Node dee81ec0), AE_AML_BUFFER_LIMIT
     ACPI-1138: *** Error: Method execution failed [\MCTH] (Node 
def2d540), AE_AML_BUFFER_LIMIT
     ACPI-1138: *** Error: Method execution failed [\OSFL] (Node 
def2d4c0), AE_AML_BUFFER_LIMIT
     ACPI-1138: *** Error: Method execution failed 
[\_SB_.PCI0.SBRG.SYSR._CRS] (Node dee811a0), AE_AML_BUFFER_LIMIT
     ACPI-0158: *** Error: Method execution failed 
[\_SB_.PCI0.SBRG.SYSR._CRS] (Node dee811a0), AE_AML_BUFFER_LIMIT


[jerry@quantum ~]$ uname -a
Linux quantum.localdomain 2.6.11-1.27_FC3smp #1 SMP Tue May 17 20:43:11 
EDT 2005 i686 i686 i386 GNU/Linux

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

Re: bug report

[Jerry DeLisle]

Jerry DeLisle wrote:
> Does the following need to be reported?  From dmesg:
Never mind, I see that it is fixed in the next version.
:)

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

Bug report

[studdugie]

Hello. I've just joined the reiserfs mailing list today because I need
to report a bug in reiser4. If this list is not the appropriate place
to report bugs, firstly, my apologies. Finally, I would appreciate
some guidance about the appropriate outlet.

I'm in quasi testing of reiser4 mode insofar as this box is concerned
and the specific app that trigged the failure but eventually I'm going
to need the app to complete w/o failure. If you (the reiser gurus)
think this is the sort of thing that has already been solved or can be
wrapped up in a short amount of time I would be glad to continue
pounding reiser4 and giving feedback.

<bug-report>
------------[ cut here ]------------
kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:32!
invalid operand: 0000 [#1]
SMP
Modules linked in:
CPU:    0
EIP:    0060:[<c021107f>]    Not tainted VLI
EFLAGS: 00010282   (2.6.11-mm2)
EIP is at get_exclusive_access+0x2f/0x40
eax: f2d5035c   ebx: f2d503c4   ecx: f73c3c98   edx: e5946e80
esi: f2d5035c   edi: f7df1d68   ebp: f7df1f3c   esp: f7df1d34
ds: 007b   es: 007b   ss: 0068
Process pdflush (pid: 111, threadinfo=f7df0000 task=c43a3020)
Stack: c0210be1 f2d5035c f7df1f3c c0208148 c04c8ba0 f2d503c4 c01ea5b1 f2d503c4
       f7344c00 f7df1e6c 00000000 00000000 00000008 00000000 00000000 00000000
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Call Trace:
 [<c0210be1>] pre_delete_unix_file+0x21/0x50
 [<c0208148>] kill_cursors+0x18/0x20
 [<c01ea5b1>] delete_inode_common+0x191/0x200
 [<c01ea679>] drop_common+0x49/0x50
 [<c01e1a30>] reiser4_drop_inode+0x20/0x40
 [<c0177ff3>] iput+0x63/0x90
 [<c0180f97>] generic_sync_sb_inodes+0x217/0x2d0
 [<c0141e60>] pdflush+0x0/0x30
 [<c01e1b7c>] reiser4_sync_inodes+0x4c/0xa0
 [<c018107e>] sync_sb_inodes+0x2e/0x40
 [<c018117c>] writeback_inodes+0xec/0x100
 [<c01413d6>] wb_kupdate+0x96/0x110
 [<c0141d8b>] __pdflush+0xbb/0x190
 [<c0141e86>] pdflush+0x26/0x30
 [<c0141340>] wb_kupdate+0x0/0x110
 [<c0141e60>] pdflush+0x0/0x30
 [<c01308da>] kthread+0xba/0xc0
 [<c0130820>] kthread+0x0/0xc0
 [<c01009f5>] kernel_thread_helper+0x5/0x10
Code: ff 8b 44 24 04 21 e2 8b 12 8b 92 b8 04 00 00 8b 52 44 8b 52 0c
85 d2 75 12 ba 01 00 ff ff f0 0f c1 10 85 d2 0f 85 0c 11 00 00 c3 <0f>
0b 20 00 c0 81 47 c0 eb e4 8d b4 26 00 00 00 00 8b 44 24 04
</bug-report>

Here is some miscellaneous output from the dmesg command that
may/maynot have a bearing on the issue.
<dmesg>
reiser4[java(7213)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[java(7213)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 32768
reiser4[java(7213)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 65536
reiser4[java(7599)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[java(7599)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 32768
reiser4[java(7599)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 65536
reiser4[ent:dm-0!(4791)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[ent:dm-0!(4791)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 32768
reiser4[ent:dm-0!(4791)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 65536
reiser4[ktxnmgrd:dm-0:r(4790)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[ent:dm-0!(4791)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[ent:dm-0!(4791)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 32768
reiser4[java(7858)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[java(7858)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 32768
reiser4[java(7858)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 65536
reiser4[java(10888)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[java(10888)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 32768
reiser4[java(10888)]: commit_current_atom
(fs/reiser4/txnmgr.c:1147)[nikita-3176]:
WARNING: Flushing like mad: 65536
</dmesg>

Below are some miscellaneous stuff that may be usefull
<misc>
mount flags: rw,noatime,nodiratime,trace=0x0,log=0x0,debug=0x0,atom_max_size=0x5f1fb
0 0

io scheduler/elevator: as
</misc>.

<system-info>
Linux cavasa 2.6.11-mm2 #4 SMP Fri Apr 8 20:26:21 EDT 2005 i686
Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux

GCC 3.3.5

GNU C Library 20040808 release version 2.3.4, by Roland McGrath et al.
Compiled by GNU CC version 3.3.5  (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
pie-8.7.7.1).
Compiled on a Linux 2.6.8 system on 2005-02-26.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
</system-info>

Dane

Re: Bug report

[Vladimir Saveliev]

Hello

On Mon, 2005-04-11 at 18:07, studdugie wrote:
> Hello. I've just joined the reiserfs mailing list today because I need
> to report a bug in reiser4. If this list is not the appropriate place
> to report bugs, firstly, my apologies. Finally, I would appreciate
> some guidance about the appropriate outlet.
> 
> I'm in quasi testing of reiser4 mode insofar as this box is concerned
> and the specific app that trigged the failure but eventually I'm going
> to need the app to complete w/o failure. If you (the reiser gurus)
> think this is the sort of thing that has already been solved or can be
> wrapped up in a short amount of time I would be glad to continue
> pounding reiser4 and giving feedback.
> 

Can you describe how to reproduce this problem?
This looks like a problem we encounter from time to time.

> <bug-report>
> ------------[ cut here ]------------
> kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:32!
> invalid operand: 0000 [#1]
> SMP
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c021107f>]    Not tainted VLI
> EFLAGS: 00010282   (2.6.11-mm2)
> EIP is at get_exclusive_access+0x2f/0x40
> eax: f2d5035c   ebx: f2d503c4   ecx: f73c3c98   edx: e5946e80
> esi: f2d5035c   edi: f7df1d68   ebp: f7df1f3c   esp: f7df1d34
> ds: 007b   es: 007b   ss: 0068
> Process pdflush (pid: 111, threadinfo=f7df0000 task=c43a3020)
> Stack: c0210be1 f2d5035c f7df1f3c c0208148 c04c8ba0 f2d503c4 c01ea5b1 f2d503c4
>        f7344c00 f7df1e6c 00000000 00000000 00000008 00000000 00000000 00000000
>        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> Call Trace:
>  [<c0210be1>] pre_delete_unix_file+0x21/0x50
>  [<c0208148>] kill_cursors+0x18/0x20
>  [<c01ea5b1>] delete_inode_common+0x191/0x200
>  [<c01ea679>] drop_common+0x49/0x50
>  [<c01e1a30>] reiser4_drop_inode+0x20/0x40
>  [<c0177ff3>] iput+0x63/0x90
>  [<c0180f97>] generic_sync_sb_inodes+0x217/0x2d0
>  [<c0141e60>] pdflush+0x0/0x30
>  [<c01e1b7c>] reiser4_sync_inodes+0x4c/0xa0
>  [<c018107e>] sync_sb_inodes+0x2e/0x40
>  [<c018117c>] writeback_inodes+0xec/0x100
>  [<c01413d6>] wb_kupdate+0x96/0x110
>  [<c0141d8b>] __pdflush+0xbb/0x190
>  [<c0141e86>] pdflush+0x26/0x30
>  [<c0141340>] wb_kupdate+0x0/0x110
>  [<c0141e60>] pdflush+0x0/0x30
>  [<c01308da>] kthread+0xba/0xc0
>  [<c0130820>] kthread+0x0/0xc0
>  [<c01009f5>] kernel_thread_helper+0x5/0x10
> Code: ff 8b 44 24 04 21 e2 8b 12 8b 92 b8 04 00 00 8b 52 44 8b 52 0c
> 85 d2 75 12 ba 01 00 ff ff f0 0f c1 10 85 d2 0f 85 0c 11 00 00 c3 <0f>
> 0b 20 00 c0 81 47 c0 eb e4 8d b4 26 00 00 00 00 8b 44 24 04
> </bug-report>
> 
> Here is some miscellaneous output from the dmesg command that
> may/maynot have a bearing on the issue.
> <dmesg>
> reiser4[java(7213)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 16384
> reiser4[java(7213)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 32768
> reiser4[java(7213)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 65536
> reiser4[java(7599)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 16384
> reiser4[java(7599)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 32768
> reiser4[java(7599)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 65536
> reiser4[ent:dm-0!(4791)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 16384
> reiser4[ent:dm-0!(4791)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 32768
> reiser4[ent:dm-0!(4791)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 65536
> reiser4[ktxnmgrd:dm-0:r(4790)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 16384
> reiser4[ent:dm-0!(4791)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 16384
> reiser4[ent:dm-0!(4791)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 32768
> reiser4[java(7858)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 16384
> reiser4[java(7858)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 32768
> reiser4[java(7858)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 65536
> reiser4[java(10888)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 16384
> reiser4[java(10888)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 32768
> reiser4[java(10888)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> WARNING: Flushing like mad: 65536
> </dmesg>
> 
These are harmless.

> Below are some miscellaneous stuff that may be usefull
> <misc>
> mount flags: rw,noatime,nodiratime,trace=0x0,log=0x0,debug=0x0,atom_max_size=0x5f1fb
> 0 0
> 
> io scheduler/elevator: as
> </misc>.
> 
> <system-info>
> Linux cavasa 2.6.11-mm2 #4 SMP Fri Apr 8 20:26:21 EDT 2005 i686
> Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux
> 
> GCC 3.3.5
> 
> GNU C Library 20040808 release version 2.3.4, by Roland McGrath et al.
> Compiled by GNU CC version 3.3.5  (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
> pie-8.7.7.1).
> Compiled on a Linux 2.6.8 system on 2005-02-26.
> Available extensions:
>         GNU libio by Per Bothner
>         crypt add-on version 2.1 by Michael Glad and others
>         Native POSIX Threads Library by Ulrich Drepper et al
>         BIND-8.2.3-T5B
>         NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> Thread-local storage support included.
> </system-info>
> 
> Dane
> 

Re: Bug report

[studdugie]

Unfortunately I can't easily and faithfully reproduce the problem
because the data set I was working against got destroyed in the
process and it's going to take a while to generate a data set of the
same size. I've tried some simple hacks to reproduce parts of the
original run but they were unable to elicit failure, so I'm convinced
that I need a data set of a similar size as the original.

On a different note, why does reiser4 take so long to mount compared
to other filesystems? I'm talking about 15 or more seconds to mount a
745GB partition.

On Apr 11, 2005 11:30 AM, Vladimir Saveliev <vs@namesys.com> wrote:
> Hello
> 
> On Mon, 2005-04-11 at 18:07, studdugie wrote:
> > Hello. I've just joined the reiserfs mailing list today because I need
> > to report a bug in reiser4. If this list is not the appropriate place
> > to report bugs, firstly, my apologies. Finally, I would appreciate
> > some guidance about the appropriate outlet.
> >
> > I'm in quasi testing of reiser4 mode insofar as this box is concerned
> > and the specific app that trigged the failure but eventually I'm going
> > to need the app to complete w/o failure. If you (the reiser gurus)
> > think this is the sort of thing that has already been solved or can be
> > wrapped up in a short amount of time I would be glad to continue
> > pounding reiser4 and giving feedback.
> >
> 
> Can you describe how to reproduce this problem?
> This looks like a problem we encounter from time to time.
> 
> > <bug-report>
> > ------------[ cut here ]------------
> > kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:32!
> > invalid operand: 0000 [#1]
> > SMP
> > Modules linked in:
> > CPU:    0
> > EIP:    0060:[<c021107f>]    Not tainted VLI
> > EFLAGS: 00010282   (2.6.11-mm2)
> > EIP is at get_exclusive_access+0x2f/0x40
> > eax: f2d5035c   ebx: f2d503c4   ecx: f73c3c98   edx: e5946e80
> > esi: f2d5035c   edi: f7df1d68   ebp: f7df1f3c   esp: f7df1d34
> > ds: 007b   es: 007b   ss: 0068
> > Process pdflush (pid: 111, threadinfo=f7df0000 task=c43a3020)
> > Stack: c0210be1 f2d5035c f7df1f3c c0208148 c04c8ba0 f2d503c4 c01ea5b1 f2d503c4
> >        f7344c00 f7df1e6c 00000000 00000000 00000008 00000000 00000000 00000000
> >        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > Call Trace:
> >  [<c0210be1>] pre_delete_unix_file+0x21/0x50
> >  [<c0208148>] kill_cursors+0x18/0x20
> >  [<c01ea5b1>] delete_inode_common+0x191/0x200
> >  [<c01ea679>] drop_common+0x49/0x50
> >  [<c01e1a30>] reiser4_drop_inode+0x20/0x40
> >  [<c0177ff3>] iput+0x63/0x90
> >  [<c0180f97>] generic_sync_sb_inodes+0x217/0x2d0
> >  [<c0141e60>] pdflush+0x0/0x30
> >  [<c01e1b7c>] reiser4_sync_inodes+0x4c/0xa0
> >  [<c018107e>] sync_sb_inodes+0x2e/0x40
> >  [<c018117c>] writeback_inodes+0xec/0x100
> >  [<c01413d6>] wb_kupdate+0x96/0x110
> >  [<c0141d8b>] __pdflush+0xbb/0x190
> >  [<c0141e86>] pdflush+0x26/0x30
> >  [<c0141340>] wb_kupdate+0x0/0x110
> >  [<c0141e60>] pdflush+0x0/0x30
> >  [<c01308da>] kthread+0xba/0xc0
> >  [<c0130820>] kthread+0x0/0xc0
> >  [<c01009f5>] kernel_thread_helper+0x5/0x10
> > Code: ff 8b 44 24 04 21 e2 8b 12 8b 92 b8 04 00 00 8b 52 44 8b 52 0c
> > 85 d2 75 12 ba 01 00 ff ff f0 0f c1 10 85 d2 0f 85 0c 11 00 00 c3 <0f>
> > 0b 20 00 c0 81 47 c0 eb e4 8d b4 26 00 00 00 00 8b 44 24 04
> > </bug-report>
> >
> > Here is some miscellaneous output from the dmesg command that
> > may/maynot have a bearing on the issue.
> > <dmesg>
> > reiser4[java(7213)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 16384
> > reiser4[java(7213)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 32768
> > reiser4[java(7213)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 65536
> > reiser4[java(7599)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 16384
> > reiser4[java(7599)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 32768
> > reiser4[java(7599)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 65536
> > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 16384
> > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 32768
> > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 65536
> > reiser4[ktxnmgrd:dm-0:r(4790)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 16384
> > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 16384
> > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 32768
> > reiser4[java(7858)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 16384
> > reiser4[java(7858)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 32768
> > reiser4[java(7858)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 65536
> > reiser4[java(10888)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 16384
> > reiser4[java(10888)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 32768
> > reiser4[java(10888)]: commit_current_atom
> > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > WARNING: Flushing like mad: 65536
> > </dmesg>
> >
> These are harmless.
> 
> > Below are some miscellaneous stuff that may be usefull
> > <misc>
> > mount flags: rw,noatime,nodiratime,trace=0x0,log=0x0,debug=0x0,atom_max_size=0x5f1fb
> > 0 0
> >
> > io scheduler/elevator: as
> > </misc>.
> >
> > <system-info>
> > Linux cavasa 2.6.11-mm2 #4 SMP Fri Apr 8 20:26:21 EDT 2005 i686
> > Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux
> >
> > GCC 3.3.5
> >
> > GNU C Library 20040808 release version 2.3.4, by Roland McGrath et al.
> > Compiled by GNU CC version 3.3.5  (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
> > pie-8.7.7.1).
> > Compiled on a Linux 2.6.8 system on 2005-02-26.
> > Available extensions:
> >         GNU libio by Per Bothner
> >         crypt add-on version 2.1 by Michael Glad and others
> >         Native POSIX Threads Library by Ulrich Drepper et al
> >         BIND-8.2.3-T5B
> >         NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> > Thread-local storage support included.
> > </system-info>
> >
> > Dane
> >
> 
>

Re: Bug report

[Vladimir Saveliev]

Hello

On Tue, 2005-04-12 at 17:57, studdugie wrote:
> Unfortunately I can't easily and faithfully reproduce the problem
> because the data set I was working against got destroyed in the
> process and it's going to take a while to generate a data set of the
> same size. I've tried some simple hacks to reproduce parts of the
> original run but they were unable to elicit failure, so I'm convinced
> that I need a data set of a similar size as the original.
> 
> On a different note, why does reiser4 take so long to mount compared
> to other filesystems? I'm talking about 15 or more seconds to mount a
> 745GB partition.

reiser4 has bitmap blocks spread uniformly over whole device. Those
blocks are to to be read on mount.

There is mount option "-o dont_load_bitmap" which speedups mount but may
make performance worse.

> 
> On Apr 11, 2005 11:30 AM, Vladimir Saveliev <vs@namesys.com> wrote:
> > Hello
> > 
> > On Mon, 2005-04-11 at 18:07, studdugie wrote:
> > > Hello. I've just joined the reiserfs mailing list today because I need
> > > to report a bug in reiser4. If this list is not the appropriate place
> > > to report bugs, firstly, my apologies. Finally, I would appreciate
> > > some guidance about the appropriate outlet.
> > >
> > > I'm in quasi testing of reiser4 mode insofar as this box is concerned
> > > and the specific app that trigged the failure but eventually I'm going
> > > to need the app to complete w/o failure. If you (the reiser gurus)
> > > think this is the sort of thing that has already been solved or can be
> > > wrapped up in a short amount of time I would be glad to continue
> > > pounding reiser4 and giving feedback.
> > >
> > 
> > Can you describe how to reproduce this problem?
> > This looks like a problem we encounter from time to time.
> > 
> > > <bug-report>
> > > ------------[ cut here ]------------
> > > kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:32!
> > > invalid operand: 0000 [#1]
> > > SMP
> > > Modules linked in:
> > > CPU:    0
> > > EIP:    0060:[<c021107f>]    Not tainted VLI
> > > EFLAGS: 00010282   (2.6.11-mm2)
> > > EIP is at get_exclusive_access+0x2f/0x40
> > > eax: f2d5035c   ebx: f2d503c4   ecx: f73c3c98   edx: e5946e80
> > > esi: f2d5035c   edi: f7df1d68   ebp: f7df1f3c   esp: f7df1d34
> > > ds: 007b   es: 007b   ss: 0068
> > > Process pdflush (pid: 111, threadinfo=f7df0000 task=c43a3020)
> > > Stack: c0210be1 f2d5035c f7df1f3c c0208148 c04c8ba0 f2d503c4 c01ea5b1 f2d503c4
> > >        f7344c00 f7df1e6c 00000000 00000000 00000008 00000000 00000000 00000000
> > >        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > Call Trace:
> > >  [<c0210be1>] pre_delete_unix_file+0x21/0x50
> > >  [<c0208148>] kill_cursors+0x18/0x20
> > >  [<c01ea5b1>] delete_inode_common+0x191/0x200
> > >  [<c01ea679>] drop_common+0x49/0x50
> > >  [<c01e1a30>] reiser4_drop_inode+0x20/0x40
> > >  [<c0177ff3>] iput+0x63/0x90
> > >  [<c0180f97>] generic_sync_sb_inodes+0x217/0x2d0
> > >  [<c0141e60>] pdflush+0x0/0x30
> > >  [<c01e1b7c>] reiser4_sync_inodes+0x4c/0xa0
> > >  [<c018107e>] sync_sb_inodes+0x2e/0x40
> > >  [<c018117c>] writeback_inodes+0xec/0x100
> > >  [<c01413d6>] wb_kupdate+0x96/0x110
> > >  [<c0141d8b>] __pdflush+0xbb/0x190
> > >  [<c0141e86>] pdflush+0x26/0x30
> > >  [<c0141340>] wb_kupdate+0x0/0x110
> > >  [<c0141e60>] pdflush+0x0/0x30
> > >  [<c01308da>] kthread+0xba/0xc0
> > >  [<c0130820>] kthread+0x0/0xc0
> > >  [<c01009f5>] kernel_thread_helper+0x5/0x10
> > > Code: ff 8b 44 24 04 21 e2 8b 12 8b 92 b8 04 00 00 8b 52 44 8b 52 0c
> > > 85 d2 75 12 ba 01 00 ff ff f0 0f c1 10 85 d2 0f 85 0c 11 00 00 c3 <0f>
> > > 0b 20 00 c0 81 47 c0 eb e4 8d b4 26 00 00 00 00 8b 44 24 04
> > > </bug-report>
> > >
> > > Here is some miscellaneous output from the dmesg command that
> > > may/maynot have a bearing on the issue.
> > > <dmesg>
> > > reiser4[java(7213)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 16384
> > > reiser4[java(7213)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 32768
> > > reiser4[java(7213)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 65536
> > > reiser4[java(7599)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 16384
> > > reiser4[java(7599)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 32768
> > > reiser4[java(7599)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 65536
> > > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 16384
> > > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 32768
> > > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 65536
> > > reiser4[ktxnmgrd:dm-0:r(4790)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 16384
> > > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 16384
> > > reiser4[ent:dm-0!(4791)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 32768
> > > reiser4[java(7858)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 16384
> > > reiser4[java(7858)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 32768
> > > reiser4[java(7858)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 65536
> > > reiser4[java(10888)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 16384
> > > reiser4[java(10888)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 32768
> > > reiser4[java(10888)]: commit_current_atom
> > > (fs/reiser4/txnmgr.c:1147)[nikita-3176]:
> > > WARNING: Flushing like mad: 65536
> > > </dmesg>
> > >
> > These are harmless.
> > 
> > > Below are some miscellaneous stuff that may be usefull
> > > <misc>
> > > mount flags: rw,noatime,nodiratime,trace=0x0,log=0x0,debug=0x0,atom_max_size=0x5f1fb
> > > 0 0
> > >
> > > io scheduler/elevator: as
> > > </misc>.
> > >
> > > <system-info>
> > > Linux cavasa 2.6.11-mm2 #4 SMP Fri Apr 8 20:26:21 EDT 2005 i686
> > > Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux
> > >
> > > GCC 3.3.5
> > >
> > > GNU C Library 20040808 release version 2.3.4, by Roland McGrath et al.
> > > Compiled by GNU CC version 3.3.5  (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
> > > pie-8.7.7.1).
> > > Compiled on a Linux 2.6.8 system on 2005-02-26.
> > > Available extensions:
> > >         GNU libio by Per Bothner
> > >         crypt add-on version 2.1 by Michael Glad and others
> > >         Native POSIX Threads Library by Ulrich Drepper et al
> > >         BIND-8.2.3-T5B
> > >         NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> > > Thread-local storage support included.
> > > </system-info>
> > >
> > > Dane
> > >
> > 
> >
> 

Re: Bug report

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Vladimir Saveliev wrote:
[...]
> reiser4 has bitmap blocks spread uniformly over whole device. Those
> blocks are to to be read on mount.
> 
> There is mount option "-o dont_load_bitmap" which speedups mount but may
> make performance worse.

Is that really "don't load" or "don't preload"?  In other words, does
this just make the FS slow for awhile, then as fast as normal as these
things get cached in RAM?  Or does this make it so that the bitmap never
gets created in RAM, and must always be read from disk?

An analogy might be Software Suspend.

A suspend can be really quick -- just swap out everything, then write
the kernel, process, and general state info out to disk.  When this
boots up, it's really quick to get back into the OS, but it's insanely
slow to actually get a desktop, because of all the seeks as it
frantically tries to load everything that's being told to reload a
window -- and it's loading everything at once, which means a thrashing
of seeks.

A suspend can also be much longer -- write out the caches, too,
basically dump at least half of RAM out to disk, and probably the whole
thing.  But when you resume this, it doesn't take much longer to get
into the OS, and you get your desktop back quicker, because everything's
already been cached with a minimum of seeks.

(Coolness:  This isn't just theoretical anymore.  I've actually gotten
suspend2 and reiser4 working on one machine, and reiser4 + unionfs +
gmailfs + kqemu + nvidia's gl drivers working on another.  I think it's
definitely stable enough to go into a 2.6 tree, even marked as
"experimental".)

If this is how reiser4 works, I think dont_load_bitmap should be the
default, because if you're going to do a bunch of seeks anyway, why not
do them as needed -- a millisecond here, a millisecond there -- instead
of all at once while the user's waiting for the thing to boot?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQl31cXgHNmZLgCUhAQK0nA//Uym9KEpYivb4OsJNXuYCQ3u9GP/K9GNa
KriyufqAo+Pth5rwBD8cgYWQwgiqZY4P8C7RsXwzKRz8ZUjt1KJ83DEekkDNPVRC
zhF1P7WWI/rlFLQEg6OWtU/tuCG36VuPZK77faxxbkrcNZoPY4k9hBL/aoKi8L9A
DagItRqDerevjhfky4OjM83cIrug4hQApxVjnpopT5LY2y4Md+ygqwtgVYHWEg6l
wwqBgtstpgrGnyId6BB9m/asI1evCuuD2NO3kzOpRuX8xgF/POnXDtVCMpUymCmb
r6IcWLlv6Z6fAk/mJ+QqpQZIflDu1Wmr+bzJ4vGznN2lkeiZU3dAdyWWVC28tofi
oJPrdfwydcYqfFr6jSGDXwqeQUrh5AYHGyPYgRH65fy4cBs3KxvY5A8135xtL0+t
CGLXKQCn6zt/Hw8xbcAusrIbi+pxE6M5BY2LspJ1SjzF/xdYs+w+foaz2/Ktnkgo
vQdQ6b0nB4RApuTx5ajJwUbuVzNDn2kTpqgSq8aZhzinIl4ILv+N1DQ+1Cnw6UON
lMv2KmVSoLEtVQSm5n6EpE6fTfh364ECNuL75cPYnuaPOH/73zQ6cOyOCukIz0oM
SiTfPPAxz+6MnAM9Qre32ksUFSZ0yp5o/FvW+pbNL0V1MLLur0uh3mj8+HXFVdtJ
vTpk7eGklig=
=T6Pu
-----END PGP SIGNATURE-----

Re: Bug report

[Vladimir Saveliev]

Hello

On Thu, 2005-04-14 at 08:45, David Masover wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Vladimir Saveliev wrote:
> [...]
> > reiser4 has bitmap blocks spread uniformly over whole device. Those
> > blocks are to to be read on mount.
> > 
> > There is mount option "-o dont_load_bitmap" which speedups mount but may
> > make performance worse.
> 
> Is that really "don't load" or "don't preload"?  In other words, does
> this just make the FS slow for awhile, then as fast as normal as these
> things get cached in RAM?  

yes

> Or does this make it so that the bitmap never
> gets created in RAM, and must always be read from disk?
> 
> An analogy might be Software Suspend.
> 
> A suspend can be really quick -- just swap out everything, then write
> the kernel, process, and general state info out to disk.  When this
> boots up, it's really quick to get back into the OS, but it's insanely
> slow to actually get a desktop, because of all the seeks as it
> frantically tries to load everything that's being told to reload a
> window -- and it's loading everything at once, which means a thrashing
> of seeks.
> 
> A suspend can also be much longer -- write out the caches, too,
> basically dump at least half of RAM out to disk, and probably the whole
> thing.  But when you resume this, it doesn't take much longer to get
> into the OS, and you get your desktop back quicker, because everything's
> already been cached with a minimum of seeks.
> 
> (Coolness:  This isn't just theoretical anymore.  I've actually gotten
> suspend2 and reiser4 working on one machine, and reiser4 + unionfs +
> gmailfs + kqemu + nvidia's gl drivers working on another.  I think it's
> definitely stable enough to go into a 2.6 tree, even marked as
> "experimental".)
> 
> If this is how reiser4 works, I think dont_load_bitmap should be the
> default, because if you're going to do a bunch of seeks anyway, why not
> do them as needed -- a millisecond here, a millisecond there -- instead
> of all at once while the user's waiting for the thing to boot?

Hans prefers waiting on boot.

> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iQIVAwUBQl31cXgHNmZLgCUhAQK0nA//Uym9KEpYivb4OsJNXuYCQ3u9GP/K9GNa
> KriyufqAo+Pth5rwBD8cgYWQwgiqZY4P8C7RsXwzKRz8ZUjt1KJ83DEekkDNPVRC
> zhF1P7WWI/rlFLQEg6OWtU/tuCG36VuPZK77faxxbkrcNZoPY4k9hBL/aoKi8L9A
> DagItRqDerevjhfky4OjM83cIrug4hQApxVjnpopT5LY2y4Md+ygqwtgVYHWEg6l
> wwqBgtstpgrGnyId6BB9m/asI1evCuuD2NO3kzOpRuX8xgF/POnXDtVCMpUymCmb
> r6IcWLlv6Z6fAk/mJ+QqpQZIflDu1Wmr+bzJ4vGznN2lkeiZU3dAdyWWVC28tofi
> oJPrdfwydcYqfFr6jSGDXwqeQUrh5AYHGyPYgRH65fy4cBs3KxvY5A8135xtL0+t
> CGLXKQCn6zt/Hw8xbcAusrIbi+pxE6M5BY2LspJ1SjzF/xdYs+w+foaz2/Ktnkgo
> vQdQ6b0nB4RApuTx5ajJwUbuVzNDn2kTpqgSq8aZhzinIl4ILv+N1DQ+1Cnw6UON
> lMv2KmVSoLEtVQSm5n6EpE6fTfh364ECNuL75cPYnuaPOH/73zQ6cOyOCukIz0oM
> SiTfPPAxz+6MnAM9Qre32ksUFSZ0yp5o/FvW+pbNL0V1MLLur0uh3mj8+HXFVdtJ
> vTpk7eGklig=
> =T6Pu
> -----END PGP SIGNATURE-----
> 

Bug report

[Ioannis Fikouras]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

[1.] One line summary of the problem: 
Kernel error message related to RAID5 and mldonkey

[2.] Full description of the problem/report:
I get this error message from the kernel shortly after stating
mldonkey. I run mldonkey on a RAID5 (3x250GB) with reiserfs. I had
similar issues witrh XFS. This error however does not seem to impact
the RAID, the FS or the apps runing on it (i.e. mldonkey, samba etc.)

[3.] Keywords (i.e., modules, networking, kernel):
RAID5, mldonkey?

[4.] Kernel version (from /proc/version):
2.6.10

[5.] Output of Oops.. message (if applicable) with symbolic information 
     resolved (see Documentation/oops-tracing.txt)
Please find attached.

[6.] A small shell script or example program which triggers the
     problem (if possible)
For me its 100% reproducible. I just need to start mldonkey. Let me
know if I can help you out with more info. A remote login would be
possible.

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Is attached

[7.2.] Processor information (from /proc/cpuinfo):
Is attached

[7.3.] Module information (from /proc/modules):
Is attached

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
Is attached

[7.5.] PCI information ('lspci -vvv' as root)
Is attached

[7.6.] SCSI information (from /proc/scsi/scsi)
No SCSI devices, funcionality only compiled as a module. Its not loaded.

[7.7.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):
/proc/mdstat is included

  Thanks a bunch, please let me know how I can help you any further.

[-- Attachment #2: bug.txt --]
[-- Type: text/plain, Size: 5431 bytes --]


sh scripts/ver_linux
~~~~~~~~~~~~~~~~~~~~~~
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux babylon 2.6.10 #1 Sat Dec 25 13:48:14 CET 2004 i686 GNU/Linux
 
Gnu C                  3.3.4
Gnu make               3.80
binutils               2.15
util-linux             2.12
mount                  2.12
module-init-tools      3.1
e2fsprogs              1.35
reiserfsprogs          3.6.19
reiser4progs           line
PPP                    2.4.2
Linux C Library        2.3.2
Dynamic linker (ldd)   2.3.2
Procps                 3.2.1
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.2.1
Modules Loaded         ipt_TCPMSS iptable_filter ipt_MASQUERADE iptable_nat ip_conntrack ip_tables af_packet nvidia_agp ehci_hcd ohci_hcd usbcore agpgart rtc unix



/var/log/mesages
~~~~~~~~~~~~~~~~~~~~~~
Dec 25 14:40:15 babylon kernel: ------------[ cut here ]------------
Dec 25 14:40:15 babylon kernel: PREEMPT 
Dec 25 14:40:15 babylon kernel: Modules linked in: ipt_TCPMSS iptable_filter ipt_MASQUERADE iptable_nat ip_conntrack ip_tables af_packet nvidia_agp ehci_hcd ohci_hcd usbcore agpgart rtc unix
Dec 25 14:40:15 babylon kernel: CPU:    0
Dec 25 14:40:15 babylon kernel: EIP:    0060:[add_stripe_bio+337/384]    Not tainted VLI
Dec 25 14:40:15 babylon kernel: EFLAGS: 00010016   (2.6.10) 
Dec 25 14:40:15 babylon kernel: EIP is at add_stripe_bio+0x151/0x180
Dec 25 14:40:15 babylon kernel: eax: 1dd1cf30   ebx: c15f7798   ecx: 1dd1cf08   edx: c721cee0
Dec 25 14:40:15 babylon kernel: esi: c721ce60   edi: 00000000   ebp: c721ce60   esp: d6589b0c
Dec 25 14:40:15 babylon kernel: ds: 007b   es: 007b   ss: 0068
Dec 25 14:40:15 babylon kernel: Process mlnet (pid: 2626, threadinfo=d6588000 task=dafc0ac0)
Dec 25 14:40:15 babylon kernel: Stack: c15f76c0 d6588000 1dd1cf08 c721ce60 c02414fa c15f76c0 c721ce60 00000001 
Dec 25 14:40:15 babylon kernel:        00000000 d6589b50 c15d7460 1dd1cf20 00000002 00000003 c15d7460 c15b49c0 
Dec 25 14:40:15 babylon kernel:        00000001 00000002 c159c1b0 df558060 d6589b8c c721ce60 c020f0e7 c159c1b0 
Dec 25 14:40:15 babylon kernel: Call Trace:
Dec 25 14:40:15 babylon kernel:  [make_request+314/624] make_request+0x13a/0x270
Dec 25 14:40:15 babylon kernel:  [generic_make_request+327/480] generic_make_request+0x147/0x1e0
Dec 25 14:40:15 babylon kernel:  [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60
Dec 25 14:40:15 babylon kernel:  [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60
Dec 25 14:40:15 babylon kernel:  [mempool_alloc+117/368] mempool_alloc+0x75/0x170
Dec 25 14:40:15 babylon kernel:  [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60
Dec 25 14:40:15 babylon kernel:  [ip_local_deliver_finish+0/480] ip_local_deliver_finish+0x0/0x1e0
Dec 25 14:40:15 babylon kernel:  [submit_bio+93/256] submit_bio+0x5d/0x100
Dec 25 14:40:15 babylon kernel:  [mpage_bio_submit+35/64] mpage_bio_submit+0x23/0x40
Dec 25 14:40:15 babylon kernel:  [do_mpage_readpage+386/944] do_mpage_readpage+0x182/0x3b0
Dec 25 14:40:15 babylon kernel:  [radix_tree_insert+226/256] radix_tree_insert+0xe2/0x100
Dec 25 14:40:15 babylon kernel:  [add_to_page_cache+104/176] add_to_page_cache+0x68/0xb0
Dec 25 14:40:15 babylon kernel:  [mpage_readpages+288/336] mpage_readpages+0x120/0x150
Dec 25 14:40:15 babylon kernel:  [reiserfs_get_block+0/5296] reiserfs_get_block+0x0/0x14b0
Dec 25 14:40:15 babylon kernel:  [read_pages+299/320] read_pages+0x12b/0x140
Dec 25 14:40:15 babylon kernel:  [reiserfs_get_block+0/5296] reiserfs_get_block+0x0/0x14b0
Dec 25 14:40:15 babylon kernel:  [__alloc_pages+464/880] __alloc_pages+0x1d0/0x370
Dec 25 14:40:15 babylon kernel:  [need_resched+39/50] need_resched+0x27/0x32
Dec 25 14:40:15 babylon kernel:  [do_page_cache_readahead+260/400] do_page_cache_readahead+0x104/0x190
Dec 25 14:40:15 babylon kernel:  [page_cache_readahead+388/480] page_cache_readahead+0x184/0x1e0
Dec 25 14:40:15 babylon kernel:  [do_generic_mapping_read+313/1328] do_generic_mapping_read+0x139/0x530
Dec 25 14:40:15 babylon kernel:  [__generic_file_aio_read+501/560] __generic_file_aio_read+0x1f5/0x230
Dec 25 14:40:15 babylon kernel:  [file_read_actor+0/224] file_read_actor+0x0/0xe0
Dec 25 14:40:15 babylon kernel:  [ip_rcv_finish+521/656] ip_rcv_finish+0x209/0x290
Dec 25 14:40:15 babylon kernel:  [generic_file_read+186/224] generic_file_read+0xba/0xe0
Dec 25 14:40:15 babylon kernel:  [scheduler_tick+31/1120] scheduler_tick+0x1f/0x460
Dec 25 14:40:15 babylon kernel:  [update_process_times+70/96] update_process_times+0x46/0x60
Dec 25 14:40:15 babylon kernel:  [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60
Dec 25 14:40:15 babylon kernel:  [timer_interrupt+85/256] timer_interrupt+0x55/0x100
Dec 25 14:40:15 babylon kernel:  [vfs_read+219/320] vfs_read+0xdb/0x140
Dec 25 14:40:15 babylon kernel:  [sys_read+81/128] sys_read+0x51/0x80
Dec 25 14:40:15 babylon kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Dec 25 14:40:15 babylon kernel: Code: c1 72 08 0f ba aa 84 00 00 00 02 5b 5e 5f 5d c3 e8 d5 3c 06 00 e9 70 ff ff ff e8 cb 3c 06 00 e9 58 ff ff ff 8b 13 e9 17 ff ff ff <0f> 0b 2d 03 7c 26 2c c0 e9 f2 fe ff ff 89 f6 6b 44 24 1c 64 8b 
Dec 25 14:40:15 babylon kernel:  <6>note: mlnet[2626] exited with preempt_count 2


[-- Attachment #3: cpu.txt --]
[-- Type: text/plain, Size: 429 bytes --]

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 3
model name	: AMD Duron(tm) processor
stepping	: 1
cpu MHz		: 801.890
cache size	: 64 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow
bogomips	: 1581.05


[-- Attachment #4: io.txt --]
[-- Type: text/plain, Size: 2247 bytes --]

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c87ff : Video ROM
000cc000-000cd7ff : Adapter ROM
000ce000-000d13ff : Adapter ROM
000d2000-000d27ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-1ffeffff : System RAM
  00100000-002a5b62 : Kernel code
  002a5b63-0034df3f : Kernel data
1fff0000-1fff2fff : ACPI Non-volatile Storage
1fff3000-1fffffff : ACPI Tables
e0000000-e1ffffff : 0000:00:00.0
e2000000-e3ffffff : PCI Bus #03
  e2000000-e3ffffff : 0000:03:00.0
    e2000000-e3ffffff : matroxfb FB
e4000000-e5ffffff : PCI Bus #02
  e5000000-e500007f : 0000:02:01.0
e6000000-e8ffffff : PCI Bus #03
  e6000000-e6003fff : 0000:03:00.0
    e6000000-e6003fff : matroxfb MMIO
  e7000000-e77fffff : 0000:03:00.0
e9000000-eaffffff : PCI Bus #01
  ea000000-ea000fff : 0000:01:08.1
    ea000000-ea000fff : ohci_hcd
  ea001000-ea0010ff : 0000:01:08.2
    ea001000-ea0010ff : ehci_hcd
  ea002000-ea002fff : 0000:01:08.0
    ea002000-ea002fff : ohci_hcd
  ea003000-ea0031ff : 0000:01:0b.0
eb003000-eb003fff : 0000:00:04.0
  eb003000-eb003fff : forcedeth
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
  03c0-03df : matrox
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
a000-cfff : PCI Bus #01
  a000-a007 : 0000:01:09.0
    a000-a007 : ide2
  a400-a403 : 0000:01:09.0
    a402-a402 : ide2
  a800-a807 : 0000:01:09.0
    a800-a807 : ide3
  ac00-ac03 : 0000:01:09.0
    ac02-ac02 : ide3
  b000-b0ff : 0000:01:09.0
    b000-b007 : ide2
    b008-b00f : ide3
    b010-b0ff : HPT370
  b400-b407 : 0000:01:0b.0
  b800-b803 : 0000:01:0b.0
  bc00-bc07 : 0000:01:0b.0
  c000-c003 : 0000:01:0b.0
  c400-c40f : 0000:01:0b.0
d000-dfff : PCI Bus #02
  d000-d07f : 0000:02:01.0
    d000-d07f : 0000:02:01.0
e000-e01f : 0000:00:01.1
e400-e407 : 0000:00:04.0
  e400-e407 : forcedeth
f000-f00f : 0000:00:09.0
  f000-f007 : ide0
  f008-f00f : ide1

[-- Attachment #5: md.txt --]
[-- Type: text/plain, Size: 171 bytes --]

Personalities : [raid5] 
md0 : active raid5 hdg1[2] hde1[1] hdc1[0]
      488391680 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]
      
unused devices: <none>

[-- Attachment #6: mods.txt --]
[-- Type: text/plain, Size: 635 bytes --]

ipt_TCPMSS 4352 1 - Live 0xe2bb8000
iptable_filter 3648 1 - Live 0xe2bb1000
ipt_MASQUERADE 3584 1 - Live 0xe2b52000
iptable_nat 27080 2 ipt_MASQUERADE, Live 0xe2be2000
ip_conntrack 46836 2 ipt_MASQUERADE,iptable_nat, Live 0xe2b93000
ip_tables 18880 4 ipt_TCPMSS,iptable_filter,ipt_MASQUERADE,iptable_nat, Live 0xe2b8d000
af_packet 22408 4 - Live 0xe2b86000
nvidia_agp 7708 1 - Live 0xe2b4a000
ehci_hcd 30980 0 - Live 0xe2b54000
ohci_hcd 18568 0 - Live 0xe2b44000
usbcore 119416 3 ehci_hcd,ohci_hcd, Live 0xe2b67000
agpgart 34344 1 nvidia_agp, Live 0xe2b3a000
rtc 12664 0 - Live 0xe083a000
unix 28724 14 - Live 0xe0831000

[-- Attachment #7: mods.txt --]
[-- Type: text/plain, Size: 635 bytes --]

ipt_TCPMSS 4352 1 - Live 0xe2bb8000
iptable_filter 3648 1 - Live 0xe2bb1000
ipt_MASQUERADE 3584 1 - Live 0xe2b52000
iptable_nat 27080 2 ipt_MASQUERADE, Live 0xe2be2000
ip_conntrack 46836 2 ipt_MASQUERADE,iptable_nat, Live 0xe2b93000
ip_tables 18880 4 ipt_TCPMSS,iptable_filter,ipt_MASQUERADE,iptable_nat, Live 0xe2b8d000
af_packet 22408 4 - Live 0xe2b86000
nvidia_agp 7708 1 - Live 0xe2b4a000
ehci_hcd 30980 0 - Live 0xe2b54000
ohci_hcd 18568 0 - Live 0xe2b44000
usbcore 119416 3 ehci_hcd,ohci_hcd, Live 0xe2b67000
agpgart 34344 1 nvidia_agp, Live 0xe2b3a000
rtc 12664 0 - Live 0xe083a000
unix 28724 14 - Live 0xe0831000

[-- Attachment #8: pci.txt --]
[-- Type: text/plain, Size: 11682 bytes --]

0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev a2)
	Subsystem: Asustek Computer, Inc.: Unknown device 80ac
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=32M]
	Capabilities: [40] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x1
	Capabilities: [60] #08 [2001]

0000:00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev a2)
	Subsystem: nVidia Corporation: Unknown device 0c17
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev a2)
	Subsystem: nVidia Corporation: Unknown device 0c17
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev a2)
	Subsystem: nVidia Corporation: Unknown device 0c17
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev a2)
	Subsystem: nVidia Corporation: Unknown device 0c17
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev a2)
	Subsystem: nVidia Corporation: Unknown device 0c17
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a3)
	Subsystem: Asustek Computer, Inc. A7N8X Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [48] #08 [01e1]

0000:00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
	Subsystem: Asustek Computer, Inc.: Unknown device 0c11
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at e000 [size=32]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1)
	Subsystem: Asustek Computer, Inc. A7N8X Mainboard onboard nForce2 Ethernet
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (250ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at eb003000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at e400 [size=8]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000a000-0000cfff
	Memory behind bridge: e9000000-eaffffff
	Prefetchable memory behind bridge: fff00000-000fffff
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

0000:00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2) (prog-if 8a [Master SecP PriP])
	Subsystem: Asustek Computer, Inc.: Unknown device 0c11
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Region 4: I/O ports at f000 [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev a3) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: e4000000-e5ffffff
	Prefetchable memory behind bridge: fff00000-000fffff
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev a2) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=32
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: e6000000-e8ffffff
	Prefetchable memory behind bridge: e2000000-e3ffffff
	BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

0000:01:08.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
	Subsystem: NEC Corporation USB
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (250ns min, 10500ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ea002000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:08.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
	Subsystem: NEC Corporation USB
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (250ns min, 10500ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin B routed to IRQ 7
	Region 0: Memory at ea000000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:08.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI])
	Subsystem: HaSoTec GmbH: Unknown device 2928
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (4000ns min, 8500ns max), Cache Line Size: 0x10 (64 bytes)
	Interrupt: pin C routed to IRQ 3
	Region 0: Memory at ea001000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:09.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 03)
	Subsystem: Triones Technologies, Inc. HPT370 UDMA100
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 120 (2000ns min, 2000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at a000 [size=8]
	Region 1: I/O ports at a400 [size=4]
	Region 2: I/O ports at a800 [size=8]
	Region 3: I/O ports at ac00 [size=4]
	Region 4: I/O ports at b000 [size=256]

0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 01)
	Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) Asus A7N8X
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at b400 [size=8]
	Region 1: I/O ports at b800 [size=4]
	Region 2: I/O ports at bc00 [size=8]
	Region 3: I/O ports at c000 [size=4]
	Region 4: I/O ports at c400 [size=16]
	Region 5: Memory at ea003000 (32-bit, non-prefetchable) [size=512]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

0000:02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated Fast Ethernet Controller [Tornado] (rev 40)
	Subsystem: Asustek Computer, Inc. A7N8X Deluxe onboard 3C920B-EMB Integrated Fast Ethernet Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at d000 [size=128]
	Region 1: Memory at e5000000 (32-bit, non-prefetchable) [size=128]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

0000:03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) (prog-if 00 [VGA])
	Subsystem: Matrox Graphics, Inc. Millennium G450 Dual Head
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (4000ns min, 8000ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 7
	Region 0: Memory at e2000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at e6000000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at e7000000 (32-bit, non-prefetchable) [size=8M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
		Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1

Bug Report

[Alan Erola]

Message:
Nov 14 04:28:24 al kernel: usb 1-1: USB disconnect, address 2
Nov 14 04:30:06 al kernel: usb 1-1: new high speed USB device using 
address 4
Nov 14 04:30:11 al wait_for_sysfs[16873]: either wait_for_sysfs (udev 
039) needs an update to handle the device 
'/devices/pci0000:00/0000:00:02.2/usb1/1-1/1-1:1.0' properly (no bus 
device link) or the sysfs-support of your device's driver needs to be 
fixed, please report to <linux-hotplug-devel@lists.sourceforge.net>
Nov 14 04:30:21 al hal.hotplug[16885]: timout(10000 ms) waiting for 
/devices/pci0000:00/0000:00:02.2/usb1/1-1/1-1:1.0

Action:
Attempting to connect Linksys WUSB54G device for wireless lan after 
installing ndiswrapper with correct Windows driver before this action. 

See full sequence:
Nov 14 04:25:25 al kernel: usb 1-1: reset high speed USB device using 
address 2
Nov 14 04:25:56 al last message repeated 86 times
Nov 14 04:26:57 al last message repeated 166 times
Nov 14 04:27:58 al last message repeated 164 times
Nov 14 04:28:24 al last message repeated 72 times
Nov 14 04:28:24 al kernel: usb 1-1: device not accepting address 2, 
error -22
Nov 14 04:28:24 al kernel: ndiswrapper (usb_reset_port:607): 
usb_reset_device() = -19
Nov 14 04:28:24 al kernel: ndiswrapper (NdisFreeSpinLock:886): incorrect 
lock 0fe97b18
Nov 14 04:28:24 al kernel: ndiswrapper (NdisFreeSpinLock:886): incorrect 
lock 0fe97b10
Nov 14 04:28:24 al kernel: ndiswrapper (ndis_init_one_usb:1630): Windows 
driver couldn't initialize the device
Nov 14 04:28:24 al kernel: rt2500usb: probe of 1-1:1.0 failed with error -22
Nov 14 04:28:24 al kernel: usbcore: registered new driver rt2500usb
Nov 14 04:28:24 al kernel: ndiswrapper: driver rt2500usb 
(Linksys,04/01/2004, 1.00.00.0000) added
Nov 14 04:28:24 al kernel: usb 1-1: USB disconnect, address 2
Nov 14 04:30:06 al kernel: usb 1-1: new high speed USB device using 
address 4
Nov 14 04:30:11 al wait_for_sysfs[16873]: either wait_for_sysfs (udev 
039) needs an update to handle the device 
'/devices/pci0000:00/0000:00:02.2/usb1/1-1/1-1:1.0' properly (no bus 
device link) or the sysfs-support of your device's driver needs to be 
fixed, please report to <linux-hotplug-devel@lists.sourceforge.net>
Nov 14 04:30:21 al hal.hotplug[16885]: timout(10000 ms) waiting for 
/devices/pci0000:00/0000:00:02.2/usb1/1-1/1-1:1.0

Environment:
Linux al.erolagroup 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004 i686 
athlon i386 GNU/Linux
Fedora Core 3

Other comments:
Was able to get device working on Fedora Core 2.






-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

bug report

[Muhtar Mahsut]

Dear Sir,

When I attempted to use ebtables for linux bridging, I had the following 
message:

wait_for_sysfs[3383]: either wait_for_sysfs (udev 039) needs an update to 
handle the device '/class/net/br0' properly (no device symlink) or the 
sysfs-support of your device's driver needs to be fixed, please report to 
<linux-hotplug-devel@lists.sourceforge.net>

Is there any suggestion?

With best regards,
Muhtar Mahsut



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: bug report

[Greg KH]

On Tue, Nov 30, 2004 at 03:31:24AM +0900, Muhtar Mahsut wrote:
> Dear Sir,
> 
> When I attempted to use ebtables for linux bridging, I had the following 
> message:
> 
> wait_for_sysfs[3383]: either wait_for_sysfs (udev 039) needs an update to 
> handle the device '/class/net/br0' properly (no device symlink) or the 
> sysfs-support of your device's driver needs to be fixed, please report to 
> <linux-hotplug-devel@lists.sourceforge.net>
> 
> Is there any suggestion?

Thanks, is fixed in newer releases.

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

bug report

[Brian Kreulen]

Got this when I tried plugging in my Dell USB keys. My USB system works, as 
I've got a cable modem, a bluetooth adaptor and a p800 usb cradle all 
working. I'm running Gentoo, latest stable. The key works fine under Windows 
(flawlessly I might add).....

God I miss devfs... at least it worked....

Dec 18 11:53:19 bkreulen usb 2-1: new full speed USB device using address 3
Dec 18 11:53:19 bkreulen scsi1 : SCSI emulation for USB Mass Storage devices
Dec 18 11:53:24 bkreulen wait_for_sysfs[8547]: either wait_for_sysfs (udev 
045) needs an update to handle the device 
'/devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1:1.0' properly (no bus device 
link) or the sysfs-support of your device's driver needsto be fixed, please 
report to <linux-hotplug-devel@lists.sourceforge.net>
-- 
Brian Kreulen


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: bug report

[Brian Kreulen]

Forgive the outburst, the problem wasn't with UDEV but with kernel modules and 
their interaction with the bios.... It's been a long night.... It works 
now...

On Saturday 18 December 2004 12:11, Brian Kreulen wrote:
> Got this when I tried plugging in my Dell USB keys. My USB system works, as
> I've got a cable modem, a bluetooth adaptor and a p800 usb cradle all
> working. I'm running Gentoo, latest stable. The key works fine under
> Windows (flawlessly I might add).....
>
> God I miss devfs... at least it worked....
>
> Dec 18 11:53:19 bkreulen usb 2-1: new full speed USB device using address 3
> Dec 18 11:53:19 bkreulen scsi1 : SCSI emulation for USB Mass Storage
> devices Dec 18 11:53:24 bkreulen wait_for_sysfs[8547]: either
> wait_for_sysfs (udev 045) needs an update to handle the device
> '/devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1:1.0' properly (no bus device
> link) or the sysfs-support of your device's driver needsto be fixed, please
> report to <linux-hotplug-devel@lists.sourceforge.net>

-- 
Brian Kreulen


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

bug report

[John Saylor]

hi

i've been trying to get my handspring visor to talk to my linux computer
over usb. i looked in the syslog and found this:

wait_for_sysfs[8575]: either wait_for_sysfs (udev 045) needs an update
to handle the device
'/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/ttyUSB1' properly
(bus specific file unavailable) or the sysfs-support of your device's
driver needs to be fixed, please report to
<linux-hotplug-devel@lists.sourceforge.net>


i believe i have compiled in the necessary kernel modules to make this
work. please let me know if you can help me, or if you need more
information from me. this is the system i am running it on [uname - a]:
Linux fripp 2.6.12-gentoo-r6 #1 Sat Jul 23 02:53:33 GMT 2005 i686
Intel(R) Pentium(R) 4 CPU 2.26GHz GenuineIntel GNU/Linux

-- 
\js    ={     http://or8.net/~johns +&:\|"    ]%}{{\|      $`}     
iraq body count: 23,589 [min] 26,705 [max] 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: bug report

[Kay Sievers]

On Sun, Aug 21, 2005 at 04:06:20PM -0400, John Saylor wrote:
> hi
> 
> i've been trying to get my handspring visor to talk to my linux computer
> over usb. i looked in the syslog and found this:
> 
> wait_for_sysfs[8575]: either wait_for_sysfs (udev 045) needs an update
> to handle the device
> '/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/ttyUSB1' properly
> (bus specific file unavailable) or the sysfs-support of your device's
> driver needs to be fixed, please report to
> <linux-hotplug-devel@lists.sourceforge.net>
> 
> 
> i believe i have compiled in the necessary kernel modules to make this
> work. please let me know if you can help me, or if you need more
> information from me. this is the system i am running it on [uname - a]:
> Linux fripp 2.6.12-gentoo-r6 #1 Sat Jul 23 02:53:33 GMT 2005 i686
> Intel(R) Pentium(R) 4 CPU 2.26GHz GenuineIntel GNU/Linux

Update your udev package and this message will go away.

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

bug report

[Michael Mey]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Hi,

I live-migrated a domU. 
dom0 and domU are Debian 3.1, domU has its VBDs on iSCSI Luns provided by a 
third machine running iscsi enterprise target.
I catched the following message in the syslog of my target machine:


Jan 11 12:09:28 testpc-018 udev[4866]: error: unknown bus, please report to 
<linux-hotplug-devel@lists.sourceforge.net> 'xen-backend'
Jan 11 12:09:28 testpc-018 udev[4871]: error: unknown bus, please report to 
<linux-hotplug-devel@lists.sourceforge.net> 'xen-backend'
Jan 11 12:09:28 testpc-018 udev[4873]: error: unknown bus, please report to 
<linux-hotplug-devel@lists.sourceforge.net> 'xen-backend'

-- 
----------------------------------------------------------------------------------------
Michael Mey                                  
Thinking Objects Software GmbH    |   mailto: michael.mey@to.com 
Lilienthalstrasse 2/1                         |   phone: +49 711 88770-147
70825 Stuttgart-Korntal, Germany  |   fax: +49 711 88770-449
----------------------------------------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: bug report

[Kay Sievers]

On Wed, Jan 11, 2006 at 12:08:56PM +0100, Michael Mey wrote:
> Hi,
> 
> I live-migrated a domU. 
> dom0 and domU are Debian 3.1, domU has its VBDs on iSCSI Luns provided by a 
> third machine running iscsi enterprise target.
> I catched the following message in the syslog of my target machine:
> 
> Jan 11 12:09:28 testpc-018 udev[4866]: error: unknown bus, please report to 
> <linux-hotplug-devel@lists.sourceforge.net> 'xen-backend'

All, hardcoded devices information is long removed from udev. This is no
longer an issue.

You can safely ignore it, it may just delay a few events for a few
seconds.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Bug report

[Manivannan Shanmugam]

Hi.

Please find here the bug report and inform us what this is and how can
we avoid this in future. We are facing difficulties with this.

Thanks.
S.Manivannan



_________________________________________________________________________________

kernel BUG at filemap.c:892!
invalid operand: 0000
nfs lockd sunrpc autofs 8139too mii ext3 jbd
CPU:    1
EIP:    0010:[unlock_page+70/112]    Not tainted
EIP:    0010:[<c0130506>]    Not tainted
EFLAGS: 00010246

EIP is at unlock_page [kernel] 0x46 (2.4.20-13.7smp)
eax: c1bbe278   ebx: c030bca0   ecx: 0000001c   edx: 00000000
esi: c1dffd54   edi: 00000000   ebp: f7402f80   esp: f76f3ef0
 ds: 0018   es: 0018   ss: 0018
Process rpciod (pid: 969, stackpage=f76f3000)
Stack: 00001000 c1bbe278 f88ec7ae f76f2000 f7402f80 f75a0380 00000046
00000000
       f759c000 f759c050 f75a7a0c 00000000 f75a0380 f88f2300 f88f2332
f736ba88
       f75a0430 d7a19774 f75a0380 f736ba74 00000001 f75a0380 f75a0424
f75a0380
Call Trace:   [<f88ec7ae>] nfs_readpage_result [nfs] 0x20e (0xf76f3ef8))
[<f88f2300>] nfs3_xdr_readres [nfs] 0x0 (0xf76f3f24))
[<f88f2332>] nfs3_xdr_readres [nfs] 0x32 (0xf76f3f28))
[<f88f2300>] nfs3_xdr_readres [nfs] 0x0 (0xf76f3f50))
[<f88bff73>] call_decode [sunrpc] 0x133 (0xf76f3f58))
[<f88c357d>] __rpc_execute [sunrpc] 0x27d (0xf76f3f78))
[do_softirq+107/208] do_softirq [kernel] 0x6b (0xf76f3f90))
[<c012107b>] do_softirq [kernel] 0x6b (0xf76f3f90))
[<f88c3742>] __rpc_schedule [sunrpc] 0xd2 (0xf76f3fb4))
[<f88c4069>] rpciod [sunrpc] 0xe9 (0xf76f3fc8))
[<f88d2128>] rpciod_killer [sunrpc] 0x0 (0xf76f3fcc))
[arch_kernel_thread+38/48] arch_kernel_thread [kernel] 0x26
(0xf76f3ff0))
[<c0107266>] arch_kernel_thread [kernel] 0x26 (0xf76f3ff0))
[<f88d2128>] rpciod_killer [sunrpc] 0x0 (0xf76f3ff4))
[<f88c3f80>] rpciod [sunrpc] 0x0 (0xf76f3ff8))


Code: 0f 0b 7c 03 50 53 25 c0 8d 46 04 39 46 04 74 10 5b 89 f0 31
	
_________________________________________________________________________________

Bug report

[Grahame M. Kelly]

[-- Attachment #1: Type: text/plain, Size: 4092 bytes --]

Hi. I hope all these details are OK.

I only have a problem with /dev/hdb1 - I get the following message with 
terminates the --rebuild-tree or --fix-fixable directives:

Replaying journal..
0 transactions replayed
Checking internal tree..
Bad root block 0. (--rebuild-tree did not complete)
Aborted


If I run --rebuild-sb I get:

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
rebuild-sb: wrong tree height occured (65535), zeroed

rebuild-sb: You either have a corrupted journal or have just changed
the start of the partition with some partition table editor. If you are
sure that the start of the partition is ok, rebuild the journal header.
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x341 of format 3.5 with standard journal
Count of blocks on the device: 2560351
Number of bitmaps: 79
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] 
blocks): 2560351
Root block: 0
Filesystem is clean
Tree height: 0
Hash function used to sort names: "r5"
Objectid map size 4, max 1004
Journal parameters:
        Device [0x0]
        Magic [0x0]
        Size 8193 blocks (including 1 for journal header) (first block 18)
        Max transaction length 1024 blocks
        Max batch size 900 blocks
        Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0xfa03:
        FATAL corruptions exist.
         some corruptions exist.
sb_version: 0
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.


Cheers, Grahame

---- Details ----

Linux glider 2.4.21-166-athlon #1 Wed Jan 7 03:05:30 UTC 2004 i686 athlon i386 
GNU/Linux (SuSE 9.0 Pro Distribution).

top - 13:38:30 up 1 day,  2:55, 11 users,  load average: 0.19, 0.59, 0.61
Tasks: 137 total,   3 running, 132 sleeping,   0 stopped,   2 zombie
Cpu(s):   6.2% user,   2.8% system,   0.0% nice,  91.1% idle
Mem:   1032852k total,   312016k used,   720836k free,    47240k buffers
Swap:  1036152k total,    60648k used,   975504k free,    67296k cached

Disk /dev/hdb: 41.1 GB, 41174138880 bytes
255 heads, 63 sectors/track, 5005 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hdb1             1      1275  10241406   83  Linux
/dev/hdb2          1276      2550  10241437+  83  Linux
/dev/hdb3          2551      3825  10241437+  83  Linux
/dev/hdb4          3826      5005   9478350   83  Linux

glider:/ # rpm -qa|grep reiser
reiserfs-3.6.9-33

glider:/proc/ide # cat drivers
ide-cdrom version 4.59-ac1
ide-floppy version 0.99.newide
ide-disk version 1.17
ide-default version 0.9.newide

glider:/proc/ide # cat amd74xx
----------AMD BusMastering IDE Configuration----------------
Driver Version:                     2.11
South Bridge:                       PCI device 10de:0065 (nVidia Corporation)
Revision:                           IDE 0xa2
Highest DMA rate:                   UDMA100
BM-DMA base:                        0xf000
PCI clock:                          33.3MHz
-----------------------Primary IDE-------Secondary IDE------
Prefetch Buffer:              yes                 yes
Post Write Buffer:            yes                 yes
Enabled:                      yes                 yes
Simplex only:                  no                  no
Cable Type:                   80w                 80w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode:       UDMA      UDMA       PIO       PIO
Address Setup:       30ns      30ns      30ns      30ns
Cmd Active:          90ns      90ns      90ns      90ns
Cmd Recovery:        30ns      30ns      30ns      30ns
Data Active:         90ns      90ns      90ns      90ns
Data Recovery:       30ns      30ns      30ns      30ns
Cycle Time:          20ns      20ns     120ns     120ns
Transfer Rate:   99.9MB/s  99.9MB/s  16.6MB/s  16.6MB/s

glider:/proc/ide # lsmod | grep ide
ide-cd                 32416   0  (autoclean)
videodev                6272   8  (autoclean) [bttv]
cdrom                  29216   0  (autoclean) [ide-cd sr_mod]

[-- Attachment #2: rebuild2.log --]
[-- Type: text/x-log, Size: 1026 bytes --]

Will rebuild the filesystem (/dev/hdb1) tree
Will put log info to '/tmp/rebuild2.log'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
0 transactions replayed
###########
reiserfsck --rebuild-tree started at Sat Feb 21 13:29:53 2004
###########

Pass 0:
Loading on-disk bitmap .. ok, 2560351 blocks marked used
Skipping 8289 blocks (super block, journal, bitmaps) 2552062 blocks will be read
0%....20%....40%....60%....80%....100%                        left 0, 9558 /sec
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 2552062
                Leaves among those 8562
                Objectids found 25649

Pass 1 (will try to insert 8562 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....Not enough allocable blocks, checking bitmap...there are 1 allocable blocks, btw

out of disk space
Aborted




####### Pass 0 #######
25647 directory entries were hashed with "r5" hash.
####### Pass 1 #######

[-- Attachment #3: smart.txt --]
[-- Type: text/plain, Size: 1920 bytes --]

smartctl version 5.1-18 Copyright (C) 2002-3 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   060    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   138   138   050    Pre-fail  Offline      -       314
  3 Spin_Up_Time            0x0007   115   115   024    Pre-fail  Always       -       187 (Average 194)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       468
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   136   136   020    Pre-fail  Offline      -       31
  9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       12128
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       466
192 Power-Off_Retract_Count 0x0032   100   100   050    Old_age   Always       -       468
193 Load_Cycle_Count        0x0012   100   100   050    Old_age   Always       -       468
194 Temperature_Celsius     0x0002   127   127   000    Old_age   Always       -       43 (Lifetime Min/Max 11/51)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       1

Re: Bug report

[Vitaly Fertman]

On Saturday 21 February 2004 05:48, Grahame M. Kelly wrote:
> Hi. I hope all these details are OK.

Hello,

could you run
	deubgreiserfs -p /dev/hdb1 | bzip2 -c > hdb1.bz2
and provide it for download, I would debug this out of disk space 
locally then.

-- 
Thanks,
Vitaly Fertman

> I only have a problem with /dev/hdb1 - I get the following message with
> terminates the --rebuild-tree or --fix-fixable directives:
>
> Replaying journal..
> 0 transactions replayed
> Checking internal tree..
> Bad root block 0. (--rebuild-tree did not complete)
> Aborted
>
>
> If I run --rebuild-sb I get:
>
> Do you want to run this program?[N/Yes] (note need to type Yes if you
> do):Yes rebuild-sb: wrong tree height occured (65535), zeroed
>
> rebuild-sb: You either have a corrupted journal or have just changed
> the start of the partition with some partition table editor. If you are
> sure that the start of the partition is ok, rebuild the journal header.
> Do you want to rebuild the journal header? (y/n)[n]: y
> Reiserfs super block in block 16 on 0x341 of format 3.5 with standard
> journal Count of blocks on the device: 2560351
> Number of bitmaps: 79
> Blocksize: 4096
> Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> blocks): 2560351
> Root block: 0
> Filesystem is clean
> Tree height: 0
> Hash function used to sort names: "r5"
> Objectid map size 4, max 1004
> Journal parameters:
>         Device [0x0]
>         Magic [0x0]
>         Size 8193 blocks (including 1 for journal header) (first block 18)
>         Max transaction length 1024 blocks
>         Max batch size 900 blocks
>         Max commit age 30
> Blocks reserved by journal: 0
> Fs state field: 0xfa03:
>         FATAL corruptions exist.
>          some corruptions exist.
> sb_version: 0
> Is this ok ? (y/n)[n]: y
> The fs may still be unconsistent. Run reiserfsck --check.
>
>
> Cheers, Grahame
>
> ---- Details ----
>
> Linux glider 2.4.21-166-athlon #1 Wed Jan 7 03:05:30 UTC 2004 i686 athlon
> i386 GNU/Linux (SuSE 9.0 Pro Distribution).
>
> top - 13:38:30 up 1 day,  2:55, 11 users,  load average: 0.19, 0.59, 0.61
> Tasks: 137 total,   3 running, 132 sleeping,   0 stopped,   2 zombie
> Cpu(s):   6.2% user,   2.8% system,   0.0% nice,  91.1% idle
> Mem:   1032852k total,   312016k used,   720836k free,    47240k buffers
> Swap:  1036152k total,    60648k used,   975504k free,    67296k cached
>
> Disk /dev/hdb: 41.1 GB, 41174138880 bytes
> 255 heads, 63 sectors/track, 5005 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
> Device Boot    Start       End    Blocks   Id  System
> /dev/hdb1             1      1275  10241406   83  Linux
> /dev/hdb2          1276      2550  10241437+  83  Linux
> /dev/hdb3          2551      3825  10241437+  83  Linux
> /dev/hdb4          3826      5005   9478350   83  Linux
>
> glider:/ # rpm -qa|grep reiser
> reiserfs-3.6.9-33
>
> glider:/proc/ide # cat drivers
> ide-cdrom version 4.59-ac1
> ide-floppy version 0.99.newide
> ide-disk version 1.17
> ide-default version 0.9.newide
>
> glider:/proc/ide # cat amd74xx
> ----------AMD BusMastering IDE Configuration----------------
> Driver Version:                     2.11
> South Bridge:                       PCI device 10de:0065 (nVidia
> Corporation) Revision:                           IDE 0xa2
> Highest DMA rate:                   UDMA100
> BM-DMA base:                        0xf000
> PCI clock:                          33.3MHz
> -----------------------Primary IDE-------Secondary IDE------
> Prefetch Buffer:              yes                 yes
> Post Write Buffer:            yes                 yes
> Enabled:                      yes                 yes
> Simplex only:                  no                  no
> Cable Type:                   80w                 80w
> -------------------drive0----drive1----drive2----drive3-----
> Transfer Mode:       UDMA      UDMA       PIO       PIO
> Address Setup:       30ns      30ns      30ns      30ns
> Cmd Active:          90ns      90ns      90ns      90ns
> Cmd Recovery:        30ns      30ns      30ns      30ns
> Data Active:         90ns      90ns      90ns      90ns
> Data Recovery:       30ns      30ns      30ns      30ns
> Cycle Time:          20ns      20ns     120ns     120ns
> Transfer Rate:   99.9MB/s  99.9MB/s  16.6MB/s  16.6MB/s
>
> glider:/proc/ide # lsmod | grep ide
> ide-cd                 32416   0  (autoclean)
> videodev                6272   8  (autoclean) [bttv]
> cdrom                  29216   0  (autoclean) [ide-cd sr_mod]

bug report

[Stephan Reichel]

proxy:/home/reichel# reiserfsck --check -l /home/reichel/rfsck.log /dev/hdb6

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.x.1b

Will read-only check consistency of the filesystem on /dev/hdb6
Will put log info to '/home/reichel/rfsck.log'

Do you want to run this program?[N/Yes] (note need to type Yes):Yes
###########
reiserfsck --check started at Sat Nov 22 21:38:48 2003
###########
Filesystem seems mounted read-only. Skipping journal replay..
Checking S+tree../  3 (of   3)/115 (of 122)/ 32 (of 170)bit 1067128968,
bitsize 8154586
reiserfsck: bitmap.c:160: reiserfs_bitmap_test_bit: Assertion `bit_number <
bm->bm_bit_size' failed.
Aborted
proxy:/home/reichel#


(I run reiserfsck because I got some errors "file '...' exists but can not
stat-ed")


Thanks in advance

Stephan Reichel
Barteldesplatz 1
D-01309 Dresden
+49 (0351) 3400111
Stephan.Reichel@1net4you.de

Re: bug report

[Vitaly Fertman]

Hello, 

On Sunday 23 November 2003 05:09, Stephan Reichel wrote:
> proxy:/home/reichel# reiserfsck --check -l /home/reichel/rfsck.log
> /dev/hdb6
>
> <-------------reiserfsck, 2002------------->
> reiserfsprogs 3.x.1b
>
> Will read-only check consistency of the filesystem on /dev/hdb6
> Will put log info to '/home/reichel/rfsck.log'
>
> Do you want to run this program?[N/Yes] (note need to type Yes):Yes
> ###########
> reiserfsck --check started at Sat Nov 22 21:38:48 2003
> ###########
> Filesystem seems mounted read-only. Skipping journal replay..
> Checking S+tree../  3 (of   3)/115 (of 122)/ 32 (of 170)bit 1067128968,
> bitsize 8154586
> reiserfsck: bitmap.c:160: reiserfs_bitmap_test_bit: Assertion `bit_number <
> bm->bm_bit_size' failed.
> Aborted
> proxy:/home/reichel#
>
>
> (I run reiserfsck because I got some errors "file '...' exists but can not
> stat-ed")

You are using a quite old riserfsprogs version, please update it to the 
latest one from our ftp site -- 
ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.11.tar.gz

-- 
Thanks,
Vitaly Fertman

bug report

[Stephan Reichel]

[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

Hello,
thanks to Vitaly for the hint.
And this is the next result:
-----------

proxy:/home/reichel# reiserfsck --rebuild-tree -l /home/reichel/rfsck.log
/dev/hdb6
reiserfsck 3.6.11 (2003 www.namesys.com)

*************************************************************
** Do not  run  the  program  with  --rebuild-tree  unless **
** something is broken and MAKE A BACKUP  before using it. **
** If you have bad sectors on a drive  it is usually a bad **
** idea to continue using it. Then you probably should get **
** a working hard drive, copy the file system from the bad **
** drive  to the good one -- dd_rescue is  a good tool for **
** that -- and only then run this program.                 **
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will rebuild the filesystem (/dev/hdb6) tree
Will put log info to '/home/reichel/rfsck.log'

Do you want to run this program?[N/Yes] (note need to type Yes if you
do):Yes

******************************************************
* Warning: The dma on your hard drive is turned off. *
* This may really slow down the fsck process.        *
******************************************************
Replaying journal..
0 transactions replayed
###########
reiserfsck --rebuild-tree started at Mon Nov 24 21:18:21 2003
###########

Pass 0:
Loading on-disk bitmap .. ok, 3472752 blocks marked used
Skipping 8459 blocks (super block, journal, bitmaps) 3464293 blocks will be
read
0%....20%....40%....60%....80%....100%                         left 0, 560
/sec
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 3464293
                Leaves among those 57850
                        - leaves all contents of which could not be saved
and deleted 1
                Objectids found 371712

Pass 1 (will try to insert 57849 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....100%                         left 0, 191
/sec
Flushing..finished
        57849 leaves read
                57428 inserted
                        - pointers in indirect items pointing to metadata 10
(zeroed)
                421 not inserted
        non-unique pointers in indirect items (zeroed) 59

Pass 2:
0%....20%....40%....60%....80%....100%                          left 0, 13
/sec
Flushing..finished
        Leaves inserted item by item 421
Pass 3 (semantic):
/old_var/spool/wwwoffle/prevout6/OrQokTtODwNeuEEihdvrfHQlbalance.c 1019
leaf_delete_items_entirely
leaf_delete_items_entirely: bad leaf 55340: level=1, nr_items=22,
free_space=65484 rdkey
Aborted

---------

See also attached log file.

Thanks,
Stephan Reichel

Re: bug report

[Carl-Daniel Hailfinger]

Stephan Reichel wrote:
> See also attached log file.

You forgot to attach it.


Carl-Daniel

Re: bug report

[Vitaly Fertman]

Hello, 

On Tuesday 25 November 2003 03:44, Stephan Reichel wrote:
> Hello,
> thanks to Vitaly for the hint.
> And this is the next result:
> -----------
>
> proxy:/home/reichel# reiserfsck --rebuild-tree -l /home/reichel/rfsck.log
> /dev/hdb6
> reiserfsck 3.6.11 (2003 www.namesys.com)
...
> Pass 3 (semantic):
> /old_var/spool/wwwoffle/prevout6/OrQokTtODwNeuEEihdvrfHQlbalance.c 1019
> leaf_delete_items_entirely
> leaf_delete_items_entirely: bad leaf 55340: level=1, nr_items=22,
> free_space=65484 rdkey
> Aborted

Hm, this is strange. 
Did you build the reiserfsprogs on the same mashine where you run it?
Would you run
    debugreiserfs -p /dev/hdb6 | bzip2 -c > hdb6.bz2
and provide it for downloading -- I will debug reiserfsck localy on your fs 
metadata if there is some bug. Although it may be some hardware problem
also -- with hdb or with the memory. 

-- 
Thanks,
Vitaly Fertman

Re: bug report

[Redeeman]

i recommend always getting the newest reiserutils

On Sun, 2003-11-23 at 03:09, Stephan Reichel wrote:
> proxy:/home/reichel# reiserfsck --check -l /home/reichel/rfsck.log /dev/hdb6
> 
> <-------------reiserfsck, 2002------------->
> reiserfsprogs 3.x.1b
> 
> Will read-only check consistency of the filesystem on /dev/hdb6
> Will put log info to '/home/reichel/rfsck.log'
> 
> Do you want to run this program?[N/Yes] (note need to type Yes):Yes
> ###########
> reiserfsck --check started at Sat Nov 22 21:38:48 2003
> ###########
> Filesystem seems mounted read-only. Skipping journal replay..
> Checking S+tree../  3 (of   3)/115 (of 122)/ 32 (of 170)bit 1067128968,
> bitsize 8154586
> reiserfsck: bitmap.c:160: reiserfs_bitmap_test_bit: Assertion `bit_number <
> bm->bm_bit_size' failed.
> Aborted
> proxy:/home/reichel#
> 
> 
> (I run reiserfsck because I got some errors "file '...' exists but can not
> stat-ed")
> 
> 
> Thanks in advance
> 
> Stephan Reichel
> Barteldesplatz 1
> D-01309 Dresden
> +49 (0351) 3400111
> Stephan.Reichel@1net4you.de
-- 
Regards, Redeeman
()  ascii ribbon campaign - against html e-mail 
/\                        - against microsoft attachments

bug report

[Russell Whitaker]

hi
Downloaded vers 1.2.8

Executing this:
  make KERNEL_DIR=/home/russ/linux-2.6.0-test2 > ../tmp 2>&1

I got:

Extensions found: IPv4:recent IPv6:ah IPv6:esp IPv6:frag IPv6:ipv6header IPv6:hbh IPv6:dst IPv6:rt
cc -O2 -Wall -Wunused -I/home/russ/linux-2.6.0-test2/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.8\"  -fPIC -o extensions/libipt_physdev_sh.o -c extensions/libipt_physdev.c
extensions/libipt_physdev.c: In function `parse':
extensions/libipt_physdev.c:86: `IPT_PHYSDEV_OP_MATCH_IN' undeclared (first use in this function)
extensions/libipt_physdev.c:86: (Each undeclared identifier is reported only once
extensions/libipt_physdev.c:86: for each function it appears in.)
extensions/libipt_physdev.c:97: `IPT_PHYSDEV_OP_MATCH_OUT' undeclared (first use in this function)
extensions/libipt_physdev.c: In function `print':
extensions/libipt_physdev.c:144: `IPT_PHYSDEV_OP_MATCH_IN' undeclared (first use in this function)
extensions/libipt_physdev.c:146: `IPT_PHYSDEV_OP_MATCH_OUT' undeclared (first use in this function)
extensions/libipt_physdev.c: In function `save':
extensions/libipt_physdev.c:156: `IPT_PHYSDEV_OP_MATCH_IN' undeclared (first use in this function)
extensions/libipt_physdev.c:158: `IPT_PHYSDEV_OP_MATCH_OUT' undeclared (first use in this function)
make: *** [extensions/libipt_physdev_sh.o] Error 1

Kernel 2.6.0-test2 seems to work OK but since don't want to run without a
firewall went back to 2.4.21 for now.

Suggestions? Fix? Patch?

Thanks,
  Russ

Re: bug report

[Russell Whitaker]

On Tue, 19 Aug 2003, dmorris wrote:

> Russell Whitaker wrote:
>
> >Kernel 2.6.0-test2 seems to work OK but since don't want to run without a
> >firewall went back to 2.4.21 for now.
> >
The next 2.6.0 patch fixed the problem, it's been OK ever since.
(Been downloading every patch and trying it so far, now  up to -test3-bk7)

Thanks for the reply
  Russ

bug report

[robs]

Having difficulty recovering a damaged ReiserFS.

Tried stuff- reiserfsck, reiserfstune, etc.  Seems to lead into an infinite
loop of things to try but don't work- ie: do x, but x needs y, but y needs
z, but z needs x.

Not sure what you need to know.

"reiserfstune" man page talks about "kernel patched with special
'relocatable journal support' patch"

   - can't find that patch.

Thanks!

Rob

Re: bug report

[Oleg Drokin]

Hello!

On Mon, Apr 28, 2003 at 04:40:49PM -0400, robs@op.net wrote:
> Having difficulty recovering a damaged ReiserFS.
> Tried stuff- reiserfsck, reiserfstune, etc.  Seems to lead into an infinite
> loop of things to try but don't work- ie: do x, but x needs y, but y needs
> z, but z needs x.
> Not sure what you need to know.
> "reiserfstune" man page talks about "kernel patched with special
> 'relocatable journal support' patch"

Well, unfortunatelly you provided not enough info at all.
We'd like to know:
what was your problem, how did you decide that reiserfs is damaged? Quote any relevant
messages from kernel/reiserfsprogs. Do you know how you get it damaged?
what reiserfsck version do you have? What steps have you already performed?
What is the kernel version?

Bye,
    Oleg

Re: bug report

[robs]

Thanks for writing back. :)

> Well, unfortunatelly you provided not enough info at all.

Of course.  I wasn't sure your needs, and rather than write a book,... :)
Firstly- there is no panic here.  I'd love to recover the data, but nothing
is at all critical, etc.  I can see the data on sectors, so I know it's
there and I can harvest anything I care to.  I'm more interested in figuring
out how to do this, and very much hopefully helping you guys. :)

I'll answer in different order-


> What is the kernel version?

2.4.20, 2.4.21-rc1-ac3, 2.5.68


> We'd like to know: what was your problem,
> how did you decide that reiserfs is damaged?

It will not mount.  Mount says: "wrong fs type, bad option, bad superblock
on /dev/hdb1, or too many mounted filesystems."

1) root (/dev/hda2) is Reiserfs, so that works. :)
2) root is only mounted filesystem (so not too many mounted)
3) specified "-t reiserfs" on mount line


> Do you know how you get it damaged?

Brilliant MS "format"- it formatted the WRONG partition.  I don't know how,
partition was different and marked "Linux 83", but leave it to MS.  I looked
at the sectors- it overwrote the MBR and everything.  I fixed the partition
table because I had the info.  "MS Format" didn't do a ton of damage,
though, and I'm hoping to get back some data, but it's not critical. :)
(In the future I will NOT run MS stuff with Linux partitions in the same
system.  I certainly will NOT run any MS "tools" with Linux partitions in
system.  Never had a problem before, but that's good old MS for you.)


> what reiserfsck version do you have?

Tried 2:

3.6.4 - came with "Slackware 9.0", the OS distro on that system.

3.6.7-pre1 - I downloaded and compiled these with gcc 3.2.2, libc 2.3.1, ...


> What steps have you already performed?

ran "reiserfsck" - it wants "--no-journal-available"

That churns and finally seems to say everything is OK. :)  But, it says I
must run "reiserfstune to specify a new journal before mounting it."

ran "reiserfsck --rebuild-sb /dev/hdb1"
ran "reiserfsck --rebuild-sb --no-journal-available /dev/hdb1"

Both say: "Reiserfs with non standard journal found, but there was not
specified any journal dev".

Not sure what to do there- the journal was always internal.

Anyway, tried "reiserfstune --make-journal-standard /dev/hdb1" and that
dumps a bunch of stuff:

---------------------------------------------------------------------

Current parameters:

Filesystem state: consistent

Reiserfs super block in block 16 on 0x341 of format 3.6 with non-standard journal
Count of blocks on the device: 1401663
Number of bitmaps: 43
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 1054508
Root block: 20
Filesystem is cleanly umounted
Tree height: 4
Hash function used to sort names: "r5"
Objectid map size 191, max 972
Journal parameters:
	Device [0x343]
	Magic [0xffffffff]
	Size 283145 blocks (including 1 for journal header) (first block 0)
	Max transaction length 1024 blocks
	Max batch size 900 blocks
	Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x0:
sb_version: 2
inode generation number: 0
UUID: d79d6899-0a1c-4349-b159-9e10e9762b65
LABEL:
Set flags in SB:
	ATTRIBUTES CLEAN
Current journal parameters:
	Device [0x343]
	Magic [0xffffffff]
	Size 283145 blocks (including 1 for journal header) (first block 0)
	Max transaction length 1024 blocks
	Max batch size 900 blocks
	Max commit age 30
ATTENTION! Filesystem with non-standard journal found. Continue? (y/n):y
reiserfstune: Can not create standard journal on separated device [0x343]

--------------------------------------------------------------------


> Quote any relevant messages from kernel/reiserfsprogs.

Nothing from kernel.


Tried "-f" options with some of above and got nowhere.  I can't find where
to get the patches you refer to in documentation- for relocatable journal,
etc.

Thanks!!!  Hope my problem helps you and your work. :)

Rob S.



On Tue, 29 Apr 2003, Oleg Drokin wrote:

> Hello!
>
> On Mon, Apr 28, 2003 at 04:40:49PM -0400, robs@op.net wrote:
> > Having difficulty recovering a damaged ReiserFS.
> > Tried stuff- reiserfsck, reiserfstune, etc.  Seems to lead into an infinite
> > loop of things to try but don't work- ie: do x, but x needs y, but y needs
> > z, but z needs x.
> > Not sure what you need to know.
> > "reiserfstune" man page talks about "kernel patched with special
> > 'relocatable journal support' patch"

Re: bug report

[Oleg Drokin]

Hello!

On Tue, Apr 29, 2003 at 04:20:44AM -0400, robs@op.net wrote:

> > Do you know how you get it damaged?
> Brilliant MS "format"- it formatted the WRONG partition.  I don't know how,
> partition was different and marked "Linux 83", but leave it to MS.  I looked
> at the sectors- it overwrote the MBR and everything.  I fixed the partition
> table because I had the info.  "MS Format" didn't do a ton of damage,
> though, and I'm hoping to get back some data, but it's not critical. :)
> (In the future I will NOT run MS stuff with Linux partitions in the same
> system.  I certainly will NOT run any MS "tools" with Linux partitions in
> system.  Never had a problem before, but that's good old MS for you.)

Unfortunatelly such a case falls under "user error" in our book. We do not
provide free support in those cases.

> Anyway, tried "reiserfstune --make-journal-standard /dev/hdb1" and that
> dumps a bunch of stuff:
> ATTENTION! Filesystem with non-standard journal found. Continue? (y/n):y
> reiserfstune: Can not create standard journal on separated device [0x343]

Well, that's where --no-journal-available option would make sence.

> Tried "-f" options with some of above and got nowhere.  I can't find where
> to get the patches you refer to in documentation- for relocatable journal,
> etc.

You don't have relocated journal anyway.

Bye,
    Oleg

Re: bug report

[robs]

Update:  I have it working.  I had to make a new separate journal device,
happened to use /dev/hdb3, then had to run:

reiserfstune --make-journal-standard -j /dev/hdb3 /dev/hdb1

etc.  Had to do it several times.  Tried it with "--no-journal-available"
but it would tell me I had a "separated journal device".  (or something like
that.)  That was the key thing I was not sure how to know what to do.
Couldn't find anything about that message anywhere in the docs. :)

Thanks again.

Rob S.



On Tue, 29 Apr 2003, Oleg Drokin wrote:

> Hello!
>
> On Mon, Apr 28, 2003 at 04:40:49PM -0400, robs@op.net wrote:
> > Having difficulty recovering a damaged ReiserFS.
> > Tried stuff- reiserfsck, reiserfstune, etc.  Seems to lead into an infinite
> > loop of things to try but don't work- ie: do x, but x needs y, but y needs
> > z, but z needs x.
> > Not sure what you need to know.
> > "reiserfstune" man page talks about "kernel patched with special
> > 'relocatable journal support' patch"
>
> Well, unfortunatelly you provided not enough info at all.
> We'd like to know:
> what was your problem, how did you decide that reiserfs is damaged? Quote any relevant
> messages from kernel/reiserfsprogs. Do you know how you get it damaged?
> what reiserfsck version do you have? What steps have you already performed?
> What is the kernel version?
>
> Bye,
>     Oleg
>

Re: bug report

[Oleg Drokin]

Hello!

On Tue, Apr 29, 2003 at 04:41:32AM -0400, robs@op.net wrote:

> Update:  I have it working.  I had to make a new separate journal device,
> happened to use /dev/hdb3, then had to run:
> reiserfstune --make-journal-standard -j /dev/hdb3 /dev/hdb1
> etc.  Had to do it several times.  Tried it with "--no-journal-available"
> but it would tell me I had a "separated journal device".  (or something like

Hm, this is strange that it did not worked, because it was supposed to.
Time to verify this stuff again, I guess.
Thanks for bringing this to our attention.

Bye,
    Oleg

bug report

[Howard Shane]

Hi,

Your warning displayed when starting reiserfsck recommended a bug report 
when the program exits with an error or fails. I have a Maxtor 60 gb 
drive that I have had problems with for the last couple of days. Upon 
accessing a certain directory, whatever program I'm using (ls, file 
manager, dump) freezes, at which point I can't access anything on the 
mountpoint.  I get the following error on running reiserfsck (debian 
reiserfsprogs 3.6.4):

    reiserfsck --check started at Mon Dec  2 13:22:46 2002
    ###########
    Replaying journal..
    0 transactions replayed
    Checking internal tree../ 86 (of  88)/ 23 (of 170)
    The problem has occurred looks like a hardware problem.
    Check your hard drive for badblocks.

    bread: Cannot read the block (22148).

When trying --rebuild-tree:

    reiserfsck --rebuild-tree started at Mon Dec  2 13:28:59 2002
    ###########

    Pass 0:
    Loading on-disk bitmap .. ok, 4893046 blocks marked used
    Skipping 8656 blocks (super block, journal, bitmaps) 4884390 blocks 
will be read
    0%                                                         left 
4884389, 0 /se                                                      left 
4873744, 5323 /sec

...at which point reiserfsck freezes completely. I have already backed 
up the data on this disk, so I don't need any support, and since it 
looks like a hardware problem I will try reformatting the disk next. 
Hope this info is of some help.

PS, I have used ext2, ext3 and xfs and think that Reiserfs is by far the 
best high performance filesystem out there. Keep up the great work.

hs

bug report

[Sander Kamphuis]

*This message was transferred with a trial version of CommuniGate(tm) Pro*
error after compiling kernel 2.4.20pre8 after applying the patch pre7 -> pre8
the following error occures after running 'make bzImage'

(translated from dutch)
make[2]: Leave map `/usr/src/linux/fs/nls'
make -C partitions
make[2]: Enter map `/usr/src/linux/fs/partitions'
make all_targets
make[3]: Enter map `/usr/src/linux/fs/partitions'
make[3]: *** No line for farget `/usr/src/linux/include/asm-ia64/efi.h', 
nessery for `efi.h'. Stop.
make[3]: Leave map `/usr/src/linux/fs/partitions'
make[2]: *** [first_rule] Error 2
make[2]: Leave map `/usr/src/linux/fs/partitions'
make[1]: *** [_subdir_partitions] Error 2
make[1]: Leave map `/usr/src/linux/fs'
make: *** [_dir_fs] Error 2



# cat /proc/version
Linux version 2.4.20-pre7 (root@sander) (gcc versie 3.1) #15 SMP vr okt 4 
14:51:49 CEST 2002

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 5
model name      : Pentium II (Deschutes)
stepping        : 1
cpu MHz         : 360.823
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 mmx fxsr
bogomips        : 719.25

# cat /proc/modules
tuner                  10404   1 (autoclean)
tvaudio                12928   0 (autoclean) (unused)
msp3400                16944   1 (autoclean)
tda9887                 2912   1 (autoclean)
bttv                   72256   0
i2c-algo-bit            7628   1 [bttv]
i2c-core               13248   0 [tuner tvaudio msp3400 tda9887 bttv 
i2c-algo-bit]
sb                      7808   2 (autoclean)
sb_lib                 39232   0 (autoclean) [sb]
uart401                 6880   0 (autoclean) [sb_lib]
sound                  60172   2 (autoclean) [sb_lib uart401]
NVdriver             1066464  10
smbfs                  39904   5 (autoclean)
parport_pc             13700   1 (autoclean)
lp                      7232   0 (autoclean)
parport                15008   1 (autoclean) [parport_pc lp]
apm                    10696   2
ne2k-pci                6016   1
8390                    6992   0 [ne2k-pci]
ide-scsi                8960   0
nls_iso8859-1           2848   4 (autoclean)
vfat                   10876   2 (autoclean)
fat                    33176   0 (autoclean) [vfat]

Re: bug report

[Paulo Andre']

On Fri, 4 Oct 2002 17:01:21 +0200
Sander Kamphuis <sander@kamphuis.dyndns.org> wrote:

> *This message was transferred with a trial version of CommuniGate(tm)
> Pro* error after compiling kernel 2.4.20pre8 after applying the patch
> pre7 -> pre8 the following error occures after running 'make bzImage'

make clean dep prior to make bzImage

	-- Paulo

Re: bug report

[Adrian Bunk]

On Fri, 4 Oct 2002, Sander Kamphuis wrote:

> *This message was transferred with a trial version of CommuniGate(tm) Pro*
> error after compiling kernel 2.4.20pre8 after applying the patch pre7 -> pre8
> the following error occures after running 'make bzImage'
>
> (translated from dutch)
> make[2]: Leave map `/usr/src/linux/fs/nls'
> make -C partitions
> make[2]: Enter map `/usr/src/linux/fs/partitions'
> make all_targets
> make[3]: Enter map `/usr/src/linux/fs/partitions'
> make[3]: *** No line for farget `/usr/src/linux/include/asm-ia64/efi.h',
> nessery for `efi.h'. Stop.
>...

You forgot to do a

  make mrproper

before starting the

  cp /path/to/.config .
  make oldconfig dep bzImage


cu
Adrian

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
								Alan Cox

Bug Report

[service]

Hello,
I received this output that requests the bug to be sent to 
linux-smp@vger.kernel.org.  I am running dual P3 tualatin-s 1.13 (512kb 
cache per chip) on a Tyan 230T with a VIA Apollo Pro133T chipset 
(VT82C694T & VT82C686B).  The motherboard can be found at 
http://www.tyan.com/products/html/tiger230t.html.

Later on in the message, it mentions that the bios might not have detected 
both processors, however this is not the case.  During post, both 
processors are clearly recognized.  If you have further questions, feel 
free to contact me.

Sincerely,
Matt


CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU0: Intel(R) Pentium(R) III CPU family      1133MHz stepping 01
per-CPU timeslice cutoff: 1463.56 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 2260.99 BogoMIPS
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check reporting enabled on CPU#1.
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU1: Intel(R) Pentium(R) III CPU family      1133MHz stepping 01
Total of 2 processors activated (4521.98 BogoMIPS).
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 
not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00178011
.......     : max redirection entries: 0017
.......     : IO APIC version: 0011
 WARNING: unexpected IO-APIC, please mail
          to linux-smp@vger.kernel.org
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 003 03  0    0    0   0   0    1    1    39
 02 003 03  0    0    0   0   0    1    1    31
 03 003 03  0    0    0   0   0    1    1    41
 04 003 03  0    0    0   0   0    1    1    49
 05 003 03  0    0    0   0   0    1    1    51
 06 003 03  0    0    0   0   0    1    1    59
 07 003 03  0    0    0   0   0    1    1    61
 08 003 03  0    0    0   0   0    1    1    69
 09 003 03  0    0    0   0   0    1    1    71
 0a 003 03  1    1    0   1   0    1    1    79
 0b 003 03  1    1    0   1   0    1    1    81
 0c 003 03  1    1    0   1   0    1    1    89
 0d 003 03  0    0    0   0   0    1    1    91
 0e 003 03  0    0    0   0   0    1    1    99
 0f 003 03  0    0    0   0   0    1    1    A1
 10 000 00  1    0    0   0   0    0    0    00
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1132.7635 MHz.
..... host bus clock speed is 133.2660 MHz.
cpu: 0, clocks: 1332660, slice: 444220
CPU0<T0:1332656,T1:888432,D:4,S:444220,C:1332660>
cpu: 1, clocks: 1332660, slice: 444220
CPU1<T0:1332656,T1:444208,D:8,S:444220,C:1332660>
checking TSC synchronization across CPUs: passed.
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs

-- 
Sincerely,
Matt M.
Staminus Communications

Voice: 949-551-3385
Email: mmahvi@staminus.net

bug report

[Pan,Gaoyong]

hi,

yestoday, my system crashed , bug report to you.

ksymoops >> kmsg  &  part of cat /var/log/messages in the fowling :

Thx

_____________________________________________________


Apr 23 19:55:01 web kernel: Unable to handle kernel paging request at
virtual address 2e72656a
Apr 23 19:55:01 web kernel:  printing eip:
Apr 23 19:55:01 web kernel: c0114e62
Apr 23 19:55:01 web kernel: *pde = 00000000
Apr 23 19:55:01 web kernel: Oops: 0000
Apr 23 19:55:01 web kernel: CPU:    0
Apr 23 19:55:01 web kernel: EIP:    0010:[__wake_up+34/160]
Apr 23 19:55:01 web kernel: EFLAGS: 00010003
Apr 23 19:55:01 web kernel: eax: c0ff97e4   ebx: 2e72656e   ecx:
00000001   edx: 00000001
Apr 23 19:55:01 web kernel: esi: cd64ee00   edi: 00000001   ebp:
cc639ef4   esp: cc639edc
Apr 23 19:55:01 web kernel: ds: 0018   es: 0018   ss: 0018
Apr 23 19:55:01 web kernel: Process python (pid: 21112,
stackpage=cc639000)
Apr 23 19:55:01 web kernel: Stack: 00000282 00000001 c0ff97e0 c0ff97e0
cd64ee00 cd64ee00 ced18860 c013f021
Apr 23 19:55:01 web kernel:        cc8d0de0 c17211e0 c013f04e cd64ee00
00000001 00000000 c0136089 cd64ee00
Apr 23 19:55:01 web kernel:        cc8d0de0 c85f4bfc 00000001 00000000
c1723c14 cc8d0de0 00000000 00000001
Apr 23 19:55:01 web kernel: Call Trace: [pipe_release+113/144]
[pipe_read_release+14/32] [fput+57/192] [filp_close+83/96]
[put_files_struct+76/208]
Apr 23 19:55:01 web kernel:    [do_exit+209/496] [do_softirq+75/144]
[do_page_fault+0/1168] [system_call+51/56]
Apr 23 19:55:01 web kernel:
Apr 23 19:55:01 web kernel: Code: 8b 4b fc 8b 01 85 45 ec 74 4e 31 c0 9c
5e fa c7 01 00 00 00
Apr 23 19:55:01 web kernel:  <1>Unable to handle kernel paging request
at virtual address 2e72656a
Apr 23 19:55:01 web kernel:  printing eip:
Apr 23 19:55:01 web kernel: c0114e62
Apr 23 19:55:01 web kernel: *pde = 00000000
Apr 23 19:55:01 web kernel: Oops: 0000
Apr 23 19:55:01 web kernel: CPU:    0
Apr 23 19:55:01 web kernel: EIP:    0010:[__wake_up+34/160]
Apr 23 19:55:01 web kernel: EFLAGS: 00010003
Apr 23 19:55:01 web kernel: eax: c0ff97e4   ebx: 2e72656e   ecx:
00000001   edx: 00000001
Apr 23 19:55:01 web kernel: esi: c833b2c0   edi: 00000001   ebp:
c9219ef4   esp: c9219edc
Apr 23 19:55:01 web kernel: ds: 0018   es: 0018   ss: 0018
Apr 23 19:55:01 web kernel: Process python (pid: 21113,
stackpage=c9219000)
Apr 23 19:55:01 web kernel: Stack: 00000282 00000001 c0ff97e0 c0ff97e0
c833b2c0 c833b2c0 ced18360 c013f021
Apr 23 19:55:01 web kernel:        c5a069c0 c17211e0 c013f04e c833b2c0
00000001 00000000 c0136089 c833b2c0
Apr 23 19:55:01 web kernel:        c5a069c0 c333fbfc 00000001 00000000
c1723c14 c5a069c0 00000000 00000001
Apr 23 19:55:02 web kernel: Call Trace: [pipe_release+113/144]
[pipe_read_release+14/32] [fput+57/192] [filp_close+83/96]
[put_files_struct+76/208]
Apr 23 19:55:02 web kernel:    [do_exit+209/496] [do_softirq+75/144]
[do_page_fault+0/1168] [system_call+51/56]
Apr 23 19:55:02 web kernel:
Apr 23 19:55:02 web kernel: Code: 8b 4b fc 8b 01 85 45 ec 74 4e 31 c0 9c
5e fa c7 01 00 00 00
Apr 23 20:00:00 web kernel:  <1>Unable to handle kernel paging request
at virtual address 2e72656a
Apr 23 20:00:00 web kernel:  printing eip:
Apr 23 20:00:00 web kernel: c0114e62
Apr 23 20:00:00 web kernel: *pde = 00000000
Apr 23 20:00:00 web kernel: Oops: 0000
Apr 23 20:00:00 web kernel: CPU:    0
Apr 23 20:00:00 web kernel: EIP:    0010:[__wake_up+34/160]
Apr 23 20:00:00 web kernel: EFLAGS: 00010003
Apr 23 20:00:00 web kernel: eax: c0ff97e4   ebx: 2e72656e   ecx:
00000001   edx: 00000001
Apr 23 20:00:00 web kernel: esi: c5dbb860   edi: 00000001   ebp:
cea81ef4   esp: cea81edc
Apr 23 20:00:00 web kernel: ds: 0018   es: 0018   ss: 0018
Apr 23 20:00:00 web kernel: Process python (pid: 21131,
stackpage=cea81000)
Apr 23 20:00:00 web kernel: Stack: 00000282 00000001 c0ff97e0 c0ff97e0
c5dbb860 c5dbb860 ca669540 c013f021
Apr 23 20:00:00 web kernel:        c3a430c0 c17211e0 c013f04e c5dbb860
00000001 00000000 c0136089 c5dbb860
Apr 23 20:00:00 web kernel:        c3a430c0 c8be7bfc 00000001 00000000
c1723c14 c3a430c0 00000000 00000001
Apr 23 20:00:00 web kernel: Call Trace: [pipe_release+113/144]
[pipe_read_release+14/32] [fput+57/192] [filp_close+83/96]
[put_files_struct+76/208]
Apr 23 20:00:00 web kernel:    [do_exit+209/496] [do_softirq+75/144]
[do_page_fault+0/1168] [system_call+51/56]
Apr 23 20:00:00 web kernel:
Apr 23 20:00:00 web kernel: Code: 8b 4b fc 8b 01 85 45 ec 74 4e 31 c0 9c
5e fa c7 01 00 00 00
Apr 23 20:00:00 web kernel:  <1>Unable to handle kernel paging request
at virtual address 77656e5b
Apr 23 20:00:00 web kernel:  printing eip:
Apr 23 20:00:00 web kernel: c0114e62
Apr 23 20:00:00 web kernel: *pde = 00000000
Apr 23 20:00:00 web kernel: Oops: 0000
Apr 23 20:00:00 web kernel: CPU:    0
Apr 23 20:00:00 web kernel: EIP:    0010:[__wake_up+34/160]
Apr 23 20:00:00 web kernel: EFLAGS: 00010887
Apr 23 20:00:00 web kernel: eax: c0ff97e4   ebx: 77656e5f   ecx:
00000001   edx: 00000001
Apr 23 20:00:00 web kernel: esi: c5dbb040   edi: 00000001   ebp:
c3c95ef4   esp: c3c95edc
Apr 23 20:00:00 web kernel: ds: 0018   es: 0018   ss: 0018
Apr 23 20:00:00 web kernel: Process python (pid: 21132,
stackpage=c3c95000)
Apr 23 20:00:00 web kernel: Stack: 00000282 00000001 c0ff97e0 c0ff97e0
c5dbb040 c5dbb040 ca669640 c013f021
Apr 23 20:00:00 web kernel:        c24175c0 c17211e0 c013f04e c5dbb040
00000001 00000000 c0136089 c5dbb040
Apr 23 20:00:00 web kernel:        c24175c0 c28e7bfc 00000001 00000000
c1723c14 c24175c0 00000000 00000001
Apr 23 20:00:00 web kernel: Call Trace: [pipe_release+113/144]
[pipe_read_release+14/32] [fput+57/192] [filp_close+83/96]
[put_files_struct+76/208]
Apr 23 20:00:00 web kernel:    [do_exit+209/496] [do_softirq+75/144]
[do_page_fault+0/1168] [system_call+51/56]
Apr 23 20:00:00 web kernel:

bug report

[Vitaly Fertman]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]


Hi all,

a problem occured while testing our mkreiserfs utility with different
blocksizes. Now we have the following situation:

ioctl (fd, BLKGETSIZE, &size) returns 5735142 of 512-byte blocks.

1. mkreiserfs /dev/hdf8 --block-size 1024
no problem, block count == 2867571

2. mkreiserfs /dev/hdf8 --blocksize 2048(or 4096)
no problem, block count == 1433785 (or 716892)

3. mount /dev/hdf8, umount

4. mkreiserfs /dev/hdf8 --blocksize 1024(or 2048)
block count == 2867567 (or 1433783), it is a bit different!

ioctl (fd, BLKGETSIZE, &size) always returns the same result,
but we just cannot read the last 3k bytes. 

The small program (attached) shows interesting results also.

After 

1. mkreiserfs /dev/hdf8 --block-size 1024
2. mount/umount

lseek64 SEEK_END to 2936392704
lseek64 to 2936392704
read a byte
lseek64 to 2936392192
read a byte
lseek64 to 2936391680
read a byte
lseek64 to 2936391168
read a byte
lseek64 to 2936390656
read a byte
lseek64 to 2936390144
read a byte
lseek64 to 2936389632
read a byte
lseek64 to 2936389120
read a byte
lseek64 to 2936388608
read a byte
lseek64 to 2936388096
read a byte
lseek64 to 2936387584
read a byte
lseek64 to 2936387072
read a byte

After 

1. mkreiserfs /dev/hdf8 --block-size 2048/4096
2. mount/umount

lseek64 SEEK_END to 2936392704
lseek64 to 2936392704
read a byte
lseek64 to 2936392192
cannot read Input/output error
lseek64 to 2936391680
cannot read Input/output error
lseek64 to 2936391168
cannot read Input/output error
lseek64 to 2936390656
cannot read Input/output error
lseek64 to 2936390144
cannot read Input/output error
lseek64 to 2936389632
cannot read Input/output error
lseek64 to 2936389120
read a byte
lseek64 to 2936388608
read a byte
lseek64 to 2936388096
read a byte
lseek64 to 2936387584
read a byte
lseek64 to 2936387072
read a byte

kernels 2.5.3, 2.4.18.

-- 

Thanks,
Vitaly Fertman

[-- Attachment #2: read_last_bytes.c --]
[-- Type: text/plain, Size: 925 bytes --]

#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64

#include <fcntl.h>
#include <sys/types.h>
#include <unistd.h>

int main ()
{
    char ch;
    loff_t res;
    int fd;
    loff_t offset;
    int i;

    offset = (unsigned long)5735142 * 512;

    fd = open ("/dev/hdf8", O_RDONLY);

    res = lseek64 (fd, 0, SEEK_END);
    if (res < 0) {
        printf ("cannot lseek64 %m\n");
        return 1;
    } else {
        printf ("lseek64 SEEK_END to %Lu\n", res);
    }

    for (i = 0; i < 12; i++) {
        res = lseek64 (fd, offset, SEEK_SET);
        if (res < 0) {
            printf ("cannot lseek64 to %Lu", offset);
	    return 1;
        } else {
            printf ("lseek64 to %Lu\n", res);
        }

        if (read (fd, &ch, 1) < 0) {
            printf ("cannot read %m\n");
//            return 1;
        } else {
            printf ("read a byte\n");
        }

        offset -= 512;
    }

    return 0;
}

Bug (?) report

[Matteo Sasso]

I'm quite a new linux user and system administrator (my own!) and I
encountered the following problems:
1) As the system starts up and the mixer settings are loaded, modprobe
complains that 'sound-slot-0' and 'sound-service-0-0' modules are not
present (in my kernel/drivers/sound directory I got just ac97_codec.o,
emu10k1, sound.o and soundcore.o). I've got a Sound Blaster Live! 5.1, a
'2.4.16-pre1' kernel and kmod usually works good, failing only with sound
(both with 'gom' mixer and with 'mpg123' player), so I have to 'modprobe
emu10k1' manually.
2) I tried for the first time to play a bit with kernel source and I was
trying to lower console_loglevel in order to have all the startup printk's
disappear. I lowered the DEFAULT_CONSOLE_LOGLEVEL constant in
'kernel/printk.c' from '7' to '5' (just to be sure) but that wasn't enough
to get rid of all those annoying KERN_INFO. Why didn't it work?

Please feel free not to answer if you don't feel like. I know I can be buggy
sometimes! :P

Thank you!
--
icemaze@tiscalinet.it

Re: Bug (?) report

[Tommy Reynolds]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

Quick to seize an opportunity, "Matteo Sasso" <icemaze@tiscalinet.it> wrote:

> I'm quite a new linux user and system administrator (my own!) and I
> encountered the following problems:
> 1) As the system starts up and the mixer settings are loaded, modprobe
> complains that 'sound-slot-0' and 'sound-service-0-0' modules are not
> present (in my kernel/drivers/sound directory I got just ac97_codec.o,
> emu10k1, sound.o and soundcore.o). I've got a Sound Blaster Live! 5.1, a
> '2.4.16-pre1' kernel and kmod usually works good, failing only with sound
> (both with 'gom' mixer and with 'mpg123' player), so I have to 'modprobe
> emu10k1' manually.

Add the following line to "/etc/modules.config":

	alias sound-slot-0 emu10k1

and then:

	# /sbin/depmod -ae

You need this because your module is named "emu10k1" but the sound system is
looking for a module named "sound-slot-0" (this is a computed module name, not
an actual name).

> 2) I tried for the first time to play a bit with kernel source and I was
> trying to lower console_loglevel in order to have all the startup printk's
> disappear. I lowered the DEFAULT_CONSOLE_LOGLEVEL constant in
> 'kernel/printk.c' from '7' to '5' (just to be sure) but that wasn't enough
> to get rid of all those annoying KERN_INFO. Why didn't it work?

You don't need to mess with that.  Just:

	# echo 5 > /proc/sys/kernel/printk

anytime you want.  Of course, since Step-1 above fixed your original problem,
you won't need to do this at all ;-)

---------------------------------------------+-----------------------------
Tommy Reynolds                               | mailto: <reynolds@redhat.com>
Red Hat, Inc., Embedded Development Services | Phone:  +1.256.704.9286
307 Wynn Drive NW, Huntsville, AL 35805 USA  | FAX:    +1.256.837.3839
Senior Software Developer                    | Mobile: +1.919.641.2923

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Bug Report

[Logoth Dragon]

1. System crashes when switching from console (frame buffer using VESA) to X session.
2. When I change to X from the console and back, after a few changes (around 3) it'll either crash the entire system (ala Windows), requiring a cold boot, or screw up the video but allow me to reboot. I have the Magic SysRq key on, and when there's a full crash even that won't work. I'm using the frame buffer with the VESA card at 1024x768x64k. This problem started after the 2.4.9 patched (including Alan's patches). The plain original 2.4.9 worked just fine.
3. kernel, video, frame buffer, X, VESA, crash, lock
4. Linux 2.4.13-ac8
5. No oops. Just plain crashing.
6. Just keep switching to and fro the console to X and it'll crash.
7.
7.1. Linux BlackTower 2.4.13-ac8 #2 SMP Wed Nov 7 13:54:22 ART 2001 i686 unknown

Gnu C                  2.95.3
Gnu make               3.79.1
binutils               2.11.90.0.19
util-linux             2.11l
mount                  2.11l
modutils               2.4.6
e2fsprogs              1.25
reiserfsprogs          3.x.0j
PPP                    2.4.1
Linux C Library        2.2.3
Dynamic linker (ldd)   2.2.3
Procps                 2.0.7
Net-tools              1.60
Kbd                    1.06
Sh-utils               2.0
Modules Loaded         sb sb_lib uart401 sound soundcore
7.2 processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 5
model name      : Pentium II (Deschutes)
stepping        : 2
cpu MHz         : 350.799
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips        : 699.59
7.3 sb                      7408   0 (unused)
sb_lib                 33456   0 [sb]
uart401                 6192   0 [sb_lib]
sound                  53504   0 [sb_lib uart401]
soundcore               3472   5 [sb_lib sound]
7.4 0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
0220-022f : soundblaster
02f8-02ff : serial(auto)
0330-0333 : MPU-401 UART
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0778-077a : parport0
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
b800-b83f : Ensoniq ES1370 [AudioPCI]
d000-d0ff : Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet
  d000-d0ff : sis900
d400-d41f : Intel Corporation 82371AB PIIX4 USB
d800-d80f : Intel Corporation 82371AB PIIX4 IDE
  d800-d807 : ide0
  d808-d80f : ide1
e400-e43f : Intel Corporation 82371AB PIIX4 ACPI
  e400-e43f : PnPBIOS PNP0c02
e800-e81f : Intel Corporation 82371AB PIIX4 ACPI
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-09ffcfff : System RAM
  00100000-00223153 : Kernel code
  00223154-00277c5f : Kernel data
09ffd000-09ffefff : ACPI Tables
09fff000-09ffffff : ACPI Non-volatile Storage
d6800000-d6800fff : Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet
  d6800000-d6800fff : sis900
d7000000-d7dfffff : PCI Bus #01
  d7000000-d707ffff : S3 Inc. Savage 4
d7f00000-e3ffffff : PCI Bus #01
  d8000000-dfffffff : S3 Inc. Savage 4
    d8000000-d9ffffff : vesafb
e4000000-e7ffffff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
ffff0000-ffffffff : reserved
7.5
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 64
	Region 0: Memory at e4000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000e000-0000dfff
	Memory behind bridge: d7000000-d7dfffff
	Prefetchable memory behind bridge: d7f00000-e3ffffff
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B+

00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 4: I/O ports at d800 [size=16]

00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Interrupt: pin D routed to IRQ 9
	Region 4: I/O ports at d400 [size=32]

00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin ? routed to IRQ 9

00:0a.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet (rev 02)
	Subsystem: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet Adapter
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (13000ns min, 2750ns max)
	Interrupt: pin A routed to IRQ 9
	Region 0: I/O ports at d000 [size=256]
	Region 1: Memory at d6800000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [40] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
	Subsystem: Unknown device 4942:4c4c
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (3000ns min, 32000ns max)
	Interrupt: pin A routed to IRQ 12
	Region 0: I/O ports at b800 [size=64]

01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 02) (prog-if 00 [VGA])
	Subsystem: Creative Labs 3d Blaster Savage 4
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (1000ns min, 63750ns max), cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at d7000000 (32-bit, non-prefetchable) [size=512K]
	Region 1: Memory at d8000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at d7ff0000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [80] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
7.6
7.7

Re: Bug Report

[Alan Cox]

> 3. kernel, video, frame buffer, X, VESA, crash, lock
> 4. Linux 2.4.13-ac8

2.4.13-ac8 isnt stable. See the release notes.

Bug report

[Daniel Glozman]

 Hi,
I was using the arch/mips/kernel/gdb-stub.c,v 1.6 file on the mips Opal design with Little Endian format. I found out that step
function was not working properly. So I debugged  little and found out the problem:
On line: 536, it says:

 	if (is_cond && targ != (regs->cp0_epc + 8)) {

The targ and regs->cp0_epc are unsigned integers and "8" is signed by default.
So what happend is that the condition didn't work as it is expected.

Please consider it in your feature versions.

Daniel.



---------------------------------
Daniel Glozman  daniel@simpod.com
SimPOD Inc.      www.simpod.com
Tel :  +972-4-9937770/203

Bug report

[Craig Cummings]

Hi there,

I think this qualifies as a bug but let me know if this could be a
configuration or hardware issue.

I've been having problems with memory leaks when I run programs on
large--up to 250MB text files.  (I know this is huge, but that's the 3
billion base human genome for you.)  At first I though it was a Perl
problem but I later found that a completely unrelated C program also
caused memory leaks.  I recently upgraded to the 2.4 kernel, hoping to
solve these problems (see below).  However, the memory leaks are still
happening and this time I know the problem is at a deeper level than my
programs.  Some standard UNIX programs are leaking a lot of memory.  I
would appreciate some advice and ultimately, a fix.  Unfortunately, My
programming skills are not sufficient for tinkering with the kernel
source.  Thank you, in advance for your help.  Details follow.

Regards,

Craig Cummings


Here are the specs for my system:
	Dell Precision XPSt700, Pentium III, 512 MB RAM
	I've recently upgraded from Red Hat 6.2 with the 2.2.14 kernel to
	Red Hat 7, then built the 2.4.2 kernel on my own.

Here's what happens with grep:

Output of free, freshly booted system:

             total       used       free     shared    buffers     cached
Mem:        513616      47516     466100          0       2476      27048
-/+ buffers/cache:      17992     495624
Swap:       128480          0     128480

Output of free after grep 'NT_005289' Data/hs_chr12.fa:

             total       used       free     shared    buffers     cached
Mem:        513616     183548     330068          0       2624     159616
-/+ buffers/cache:      21308     492308
Swap:       128480          0     128480

Output of grep 'NT_005289' Data/hs_chr2.fa:

>gi|12728771|ref|NT_005289.2|Hs2_5446 Homo sapiens chromosome 2 working draft sequence segment

Output of free after this grep:

             total       used       free     shared    buffers     cached
Mem:        513616     424272      89344          0       2860     394232
-/+ buffers/cache:      27180     486436
Swap:       128480          0     128480

Output of grep 'NT_005289' Data/hs_chr2.fa:

>gi|12728771|ref|NT_005289.2|Hs2_5446 Homo sapiens chromosome 2 working draft sequence segment

Output of free after this grep:

             total       used       free     shared    buffers     cached
Mem:        513616     424272      89344          0       2860     394232
-/+ buffers/cache:      27180     486436
Swap:       128480          0     128480

File sizes of the two files grep'ed:

-rw-rw-r--    1 cummings genomics 135744469 Mar 12 22:09 Data/hs_chr12.fa
-rw-rw-r--    1 cummings genomics 240244039 Mar 12 22:24 Data/hs_chr2.fa

Note that these file sizes are equivalent to the amount of memory leaked
when grep is called on that file.

When I grep the same file a second time, very little additional memory is
leaked.


This same phenomenon occurs when I run a different UNIX program, e.g. wc:

Output of wc -l Data/hs_chr3.fa:

2915465 Data/hs_chr3.fa

Output of free:

             total       used       free     shared    buffers     cached
Mem:        513616     511520       2096          0       1252     481020
-/+ buffers/cache:      29248     484368
Swap:       128480          0     128480

Interestingly, after running wc a second time on the same file, it goes
very fast and very little additional memory is leaked:

             total       used       free     shared    buffers     cached
Mem:        513616     510732       2884          0       1204     480948
-/+ buffers/cache:      28580     485036
Swap:       128480         40     128440


-------------------------------------------
Craig Cummings, Ph.D.

Relman Laboratory
Stanford University School of Medicine
Department of Microbiology and Immunology

e-mail: cummings@cmgm.stanford.edu
phone:  650-498-5998
fax:    650-852-3291

Re: Bug report

[Tim Walberg]

[-- Attachment #1: Type: text/plain, Size: 5132 bytes --]

"User does not understand how *NIX systems utilize memory" is
not the same thing as "bug". What you are seeing is the kernel
using memory for file system cache.

On 03/22/2001 12:58 -0800, Craig Cummings wrote:
>>	Hi there,
>>	
>>	I think this qualifies as a bug but let me know if this could be a
>>	configuration or hardware issue.
>>	
>>	I've been having problems with memory leaks when I run programs on
>>	large--up to 250MB text files.  (I know this is huge, but that's the 3
>>	billion base human genome for you.)  At first I though it was a Perl
>>	problem but I later found that a completely unrelated C program also
>>	caused memory leaks.  I recently upgraded to the 2.4 kernel, hoping to
>>	solve these problems (see below).  However, the memory leaks are still
>>	happening and this time I know the problem is at a deeper level than my
>>	programs.  Some standard UNIX programs are leaking a lot of memory.  I
>>	would appreciate some advice and ultimately, a fix.  Unfortunately, My
>>	programming skills are not sufficient for tinkering with the kernel
>>	source.  Thank you, in advance for your help.  Details follow.
>>	
>>	Regards,
>>	
>>	Craig Cummings
>>	
>>	
>>	Here are the specs for my system:
>>		Dell Precision XPSt700, Pentium III, 512 MB RAM
>>		I've recently upgraded from Red Hat 6.2 with the 2.2.14 kernel to
>>		Red Hat 7, then built the 2.4.2 kernel on my own.
>>	
>>	Here's what happens with grep:
>>	
>>	Output of free, freshly booted system:
>>	
>>	             total       used       free     shared    buffers     cached
>>	Mem:        513616      47516     466100          0       2476      27048
>>	-/+ buffers/cache:      17992     495624
>>	Swap:       128480          0     128480
>>	
>>	Output of free after grep 'NT_005289' Data/hs_chr12.fa:
>>	
>>	             total       used       free     shared    buffers     cached
>>	Mem:        513616     183548     330068          0       2624     159616
>>	-/+ buffers/cache:      21308     492308
>>	Swap:       128480          0     128480
>>	
>>	Output of grep 'NT_005289' Data/hs_chr2.fa:
>>	
>>	>gi|12728771|ref|NT_005289.2|Hs2_5446 Homo sapiens chromosome 2 working draft sequence segment
>>	
>>	Output of free after this grep:
>>	
>>	             total       used       free     shared    buffers     cached
>>	Mem:        513616     424272      89344          0       2860     394232
>>	-/+ buffers/cache:      27180     486436
>>	Swap:       128480          0     128480
>>	
>>	Output of grep 'NT_005289' Data/hs_chr2.fa:
>>	
>>	>gi|12728771|ref|NT_005289.2|Hs2_5446 Homo sapiens chromosome 2 working draft sequence segment
>>	
>>	Output of free after this grep:
>>	
>>	             total       used       free     shared    buffers     cached
>>	Mem:        513616     424272      89344          0       2860     394232
>>	-/+ buffers/cache:      27180     486436
>>	Swap:       128480          0     128480
>>	
>>	File sizes of the two files grep'ed:
>>	
>>	-rw-rw-r--    1 cummings genomics 135744469 Mar 12 22:09 Data/hs_chr12.fa
>>	-rw-rw-r--    1 cummings genomics 240244039 Mar 12 22:24 Data/hs_chr2.fa
>>	
>>	Note that these file sizes are equivalent to the amount of memory leaked
>>	when grep is called on that file.
>>	
>>	When I grep the same file a second time, very little additional memory is
>>	leaked.
>>	
>>	
>>	This same phenomenon occurs when I run a different UNIX program, e.g. wc:
>>	
>>	Output of wc -l Data/hs_chr3.fa:
>>	
>>	2915465 Data/hs_chr3.fa
>>	
>>	Output of free:
>>	
>>	             total       used       free     shared    buffers     cached
>>	Mem:        513616     511520       2096          0       1252     481020
>>	-/+ buffers/cache:      29248     484368
>>	Swap:       128480          0     128480
>>	
>>	Interestingly, after running wc a second time on the same file, it goes
>>	very fast and very little additional memory is leaked:
>>	
>>	             total       used       free     shared    buffers     cached
>>	Mem:        513616     510732       2884          0       1204     480948
>>	-/+ buffers/cache:      28580     485036
>>	Swap:       128480         40     128440
>>	
>>	
>>	-------------------------------------------
>>	Craig Cummings, Ph.D.
>>	
>>	Relman Laboratory
>>	Stanford University School of Medicine
>>	Department of Microbiology and Immunology
>>	
>>	e-mail: cummings@cmgm.stanford.edu
>>	phone:  650-498-5998
>>	fax:    650-852-3291
>>	
>>	-
>>	To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>	the body of a message to majordomo@vger.kernel.org
>>	More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>	Please read the FAQ at  http://www.tux.org/lkml/
End of included message



-- 
+--------------------------+------------------------------+
| Tim Walberg              | tewalberg@mediaone.net       |
| 828 Marshall Ct.         | www.concentric.net/~twalberg |
| Palatine, IL 60074       |                              |
+--------------------------+------------------------------+

[-- Attachment #2: Type: application/pgp-signature, Size: 175 bytes --]

Bug report

[Anders S. Buch]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 9300 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

It seems that the ide/cdrom/amd756 code can cause some bad lockups, at
least on my system.  I have an Athlon 500 system running the 2.4.1 kernel
with Redhat 6.1 + updated modutils, etc.

I just managed to make the kernel lockup as follows:

I mounted my cdrom drive (a ZipCD 4x650 ATAPI CD-RW), and did a
rpm --nodeps -i /mnt/cdrom/RedHat/RPMS/xgammon-bla-bla.rpm

If I instead just did a "cp /mnt/cdrom/RedHat/RPMS/xgammon-bla-bla.rpm ."
things seemed to work fine.

The lockup was very "complete": even the power button on the front of
my box didn't do anything.  I had to use the BIG BLACK power switch on
the back side to get it back to life.  I have never seen this before.
(My computer doesn't have a reset button, it must be made for linux!!)

Also, when I reproduced the lockup in text-mode, I didn't even get the
normal oops-dump, the system just froze.

My motherboard has an AMD 756 chipset, I wonder if this means
anything.  I did enable the 7409 support in my kernel
(CONFIG_BLK_DEV_AMD7409=y).

Here is some stuff from dmesg (the full dmesg is below):

AMD7409: IDE controller on PCI bus 00 dev 39
AMD7409: chipset revision 3
AMD7409: not 100% native mode: will probe irqs later
AMD7409: disabling single-word DMA support (revision < C4)
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:DMA

And some stuff from /var/log/messages:

Jan 31 22:09:09 localhost kernel: usb-ohci.c: bogus NDP=96 for OHCI usb-00:07.4
Jan 31 22:09:09 localhost kernel: usb-ohci.c: rereads as NDP=4
Jan 31 22:16:32 localhost kernel: usb-ohci.c: bogus NDP=96 for OHCI usb-00:07.4
Jan 31 22:16:32 localhost kernel: usb-ohci.c: rereads as NDP=4

and more:

Jan 31 22:37:31 localhost kernel: usb-ohci.c: bogus NDP=128 for OHCI usb-00:07.4
Jan 31 22:37:31 localhost kernel: usb-ohci.c: rereads as NDP=4


Regarding error output from the actual lockups, I usually run my cd-rw
drive as an scsi device using ide-scsi.  When I did this, I got some
error output on the screen which also appeared in /var/log/messages.
At one lockup event I got lots of the following:

Feb  1 15:16:10 localhost kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 0x00 00 00 00 00 00
Feb  1 15:16:20 localhost kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 0x00 00 00 00 00 00
Feb  1 15:16:20 localhost kernel: SCSI host 0 abort (pid 0) timed out - resetting
Feb  1 15:16:20 localhost kernel: SCSI bus is being reset for host 0 channel 0.
Feb  1 15:16:20 localhost kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 0x00 00 00 00 00 00
Feb  1 15:16:20 localhost kernel: SCSI host 0 abort (pid 0) timed out - resetting
Feb  1 15:16:20 localhost kernel: SCSI bus is being reset for host 0 channel 0.
Feb  1 15:16:21 localhost kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 0x00 00 00 00 00 00
Feb  1 15:16:21 localhost kernel: SCSI host 0 abort (pid 0) timed out - resetting
Feb  1 15:16:21 localhost kernel: SCSI bus is being reset for host 0 channel 0.
...
Feb  1 15:16:29 localhost kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 0x00 00 00 00 00 00
Feb  1 15:16:29 localhost kernel: SCSI host 0 abort (pid 0) timed out - resetting
Feb  1 15:16:29 localhost kernel: SCSI bus is being reset for host 0 channel 0.
Feb  1 15:20:32 localhost syslogd 1.3-3: restart.

At other times, I just got some error messages when using the above rpm
command:

Feb  1 15:27:18 localhost kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Feb  1 15:27:18 localhost kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
Feb  1 15:27:18 localhost kernel: Uniform CD-ROM driver Revision: 3.12
Feb  1 15:27:25 localhost modprobe: modprobe: Can't locate module nls_iso8859-1
Feb  1 15:27:25 localhost modprobe: modprobe: Can't locate module nls_cp437
Feb  1 15:29:09 localhost kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Feb  1 15:29:09 localhost kernel: hdd: DMA disabled
Feb  1 15:29:12 localhost kernel: hdd: ATAPI reset complete
Feb  1 15:29:12 localhost kernel:  I/O error: dev 0b:00, sector 1303020
Feb  1 15:29:12 localhost kernel:  I/O error: dev 0b:00, sector 1303020
Feb  1 15:29:12 localhost kernel:  I/O error: dev 0b:00, sector 1303276
Feb  1 15:29:12 localhost kernel:  I/O error: dev 0b:00, sector 1303020
Feb  1 15:29:12 localhost kernel:  I/O error: dev 0b:00, sector 1303020


Finally, I have also had lockup problems with my USB port, which
seems to be run by the same AMD 756 chip.  I will attach a bug report
about this issue.  However, I can reproduce the cdrom lockups also when no
usb-modules are loaded.

Well, thanks for the great hacking!!  I hope this can help making the
kernel even better!  If I can supply you with more information, please
let me know.

Sincerely, Anders Buch


Full /var/log/dmesg:

Linux version 2.4.1 (abuch@localhost.localdomain) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Jan 30 11:12:07 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
 BIOS-e820: 0000000000000400 @ 000000000009fc00 (reserved)
 BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
 BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
 BIOS-e820: 0000000007ef0000 @ 0000000000100000 (usable)
 BIOS-e820: 000000000000d000 @ 0000000007ff3000 (ACPI data)
 BIOS-e820: 0000000000003000 @ 0000000007ff0000 (ACPI NVS)
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=241 ro root=306 ramdisk=0
Initializing CPU#0
Detected 499.045 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 996.14 BogoMIPS
Memory: 127272k/131008k available (681k kernel code, 3348k reserved, 225k data, 56k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 0081f9ff c0c1f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After vendor init, caps: 0081f9ff c0c1f9ff 00000000 00000000
CPU: After generic, caps: 0081f9ff c0c1f9ff 00000000 00000000
CPU: Common caps: 0081f9ff c0c1f9ff 00000000 00000000
CPU: AMD-K7(tm) Processor stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.1 present.
29 structures occupying 743 bytes.
DMI table at 0x000F0800.
BIOS Vendor: Award Software International, Inc.
BIOS Version: 4.51 PG
BIOS Release: 10/01/99
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 84552kB/28184kB, 256 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD7409: IDE controller on PCI bus 00 dev 39
AMD7409: chipset revision 3
AMD7409: not 100% native mode: will probe irqs later
AMD7409: disabling single-word DMA support (revision < C4)
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:DMA
hda: IBM-DJNA-371350, ATA DISK drive
hdd: ZIPCD 4x650, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 26520480 sectors (13578 MB) w/1966KiB Cache, CHS=26310/16/63, UDMA(33)
Partition check:
 hda: hda1 hda2 < hda5 hda6 hda7 > hda3
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS02 at 0x03e8 (irq = 4) is a 16550A
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 56k freed
Adding Swap: 102776k swap-space (priority -1)
es1371: version v0.27 time 11:16:28 Jan 30 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x06
es1371: found es1371 rev 6 at io 0xe400 irq 11
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x5452:0x4103 (TriTech TR?????)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub


- ----

Anders Skovsted Buch        Phone:  (617) 253-4399
MIT Room 2-275              Fax:    (617) 253-4358
77 Massachusetts Ave        E-mail: abuch@math.mit.edu
Cambridge, MA 02139         http://www-math.mit.edu/~abuch/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE6ed61WyfD6jrb5n4RAhz+AJ9hu5GiH6lh6DnquQKgp83GDQhPGgCfdNpJ
Pxv1jCClXB7tket99Auua0M=
=5TNj
-----END PGP SIGNATURE-----

[-- Attachment #2: Type: TEXT/plain, Size: 29470 bytes --]

Hello,

This is the same bug as I reported a week ago, but this time with the
2.4.1 kernel and support for hot pluggable devices compiled in.

I am using usb-ohci.o and printer.o on an Athlon 500 system, with
Redhat 6.1, kernel 2.4.1, updated modutils, etc.

I have a printer (Epson 980) connected to my USB port.  If I turn my
printer off and immediately after cat a large file to /dev/usb/lp0,
then the kernel oops'es and locks up.

Below is some data.  Thanks for the great hacking!!

Sincerely, Anders Buch


--------------------------------------------
Last lines in /var/log/messages before oops:
--------------------------------------------

Jan 30 20:34:09 localhost kernel: hub.c: USB new device connect on bus1/1, assigned device number 2 
Jan 30 20:34:09 localhost kernel: printer.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 
Jan 30 20:34:54 localhost kernel: printer.c: usblp0: nonzero read/write bulk status received: -110 
Jan 30 20:34:54 localhost kernel: printer.c: usblp0: nonzero read/write bulk status received: -110 
Jan 30 20:34:54 localhost kernel: printer.c: usblp0: failed reading printer status 
Jan 30 20:54:32 localhost syslogd 1.3-3: restart.


---------------------------------------------
Opps dump on screen: (copied down by hand...)
---------------------------------------------

printer.c: usblp0: failed reading printer status
printer.c: usblp0: failed reading printer status
printer.c: usblp0: failed reading printer status
printer.c: usblp0: failed reading printer status
printer.c: usblp0: failed reading printer status
printer.c: usblp0: failed reading printer status
printer.c: usblp0: failed reading printer status
usb-ohci.c: bus 00:07.4 devnum 2 deletion in interrupt
kernel BUG at usb-ohci.c:779!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c8826a29>]
EFLAGS: 00010092
eax: 0000001e   ebx: c7c1b400   ecx: c7a2c000   edx: 00000001
esi: c7c1b418   edi: 00000020   ebp: 00000003   esp: c01e5e68
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c01e5000)
Stack: c8829756 c8829977 0000030b c72b6000 c6872520 c7c1b000 c6872520 c7875000
       c7c1b000 00000002 00000000 c01f73c7 c01f7386 00000000 c01d69c8 00000282
       00000082 00000003 c6872520 c6872530 c6872520 c74d3eb0 00068720 c8826093
Call Trace: [<c8829756>] [<c8829977>] [<c8826093>] [<c8819dee>] [<c88260ef>] [<c882610a>] [<c882621c>]
       [<c8827da4>] [<c882c00c>] [<c882c000>] [<c8828db8>] [<c882c014>] [<c8829977>] [<c882c010>] [<c882c00c>]
       [<c0109f1d>] [<c010a087>] [<c0107160>] [<c0107160>] [<c0108e28>] [<c0107160>] [<c0107160>] [<c0107183>]
       [<c01071e4>] [<c0105000>] [<c0100192>]

Code: 0f 0b 83 c4 0c 89 f6 8b 4c 24 14 51 e8 5a d9 8f f7 83 c4 04
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing


-----------------------------
Output from ksymoops:
-----------------------------

ksymoops 2.3.7 on i686 2.4.1.  Options used
     -V (default)
     -k proc.ksyms.txt (specified)
     -l proc.modules.txt (specified)
     -o /lib/modules/2.4.1/ (default)
     -m /boot/System.map-2.4.1 (specified)

kernel BUG at usb-ohci.c:779!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c8826a29>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010092
eax: 0000001e   ebx: c7c1b400   ecx: c7a2c000   edx: 00000001
esi: c7c1b418   edi: 00000020   ebp: 00000003   esp: c01e5e68
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c01e5000)
Stack: c8829756 c8829977 0000030b c72b6000 c6872520 c7c1b000 c6872520 c7875000
       c7c1b000 00000002 00000000 c01f73c7 c01f7386 00000000 c01d69c8 00000282
       00000082 00000003 c6872520 c6872530 c6872520 c74d3eb0 00068720 c8826093
Call Trace: [<c8829756>] [<c8829977>] [<c8826093>] [<c8819dee>] [<c88260ef>] [<c882610a>] [<c882621c>]
       [<c8827da4>] [<c882c00c>] [<c882c000>] [<c8828db8>] [<c882c014>] [<c8829977>] [<c882c010>] [<c882c00c>]
       [<c0109f1d>] [<c010a087>] [<c0107160>] [<c0107160>] [<c0108e28>] [<c0107160>] [<c0107160>] [<c0107183>]
       [<c01071e4>] [<c0105000>] [<c0100192>]
Code: 0f 0b 83 c4 0c 89 f6 8b 4c 24 14 51 e8 5a d9 8f f7 83 c4 04

>>EIP; c8826a29 <[usb-ohci]sohci_free_dev+1e9/208>   <=====
Trace; c8829756 <[usb-ohci].rodata.start+36/72c>
Trace; c8829977 <[usb-ohci].rodata.start+257/72c>
Trace; c8826093 <[usb-ohci]urb_free_priv+33/3c>
Trace; c8819dee <[usbcore]usb_free_dev+1e/30>
Trace; c88260ef <[usb-ohci]urb_rm_priv_locked+53/60>
Trace; c882610a <[usb-ohci]urb_rm_priv+e/18>
Trace; c882621c <[usb-ohci]sohci_return_urb+108/118>
Trace; c8827da4 <[usb-ohci]dl_done_list+b4/118>
Trace; c882c00c <[usb-ohci].data.end+20ad/4101>
Trace; c882c000 <[usb-ohci].data.end+20a1/4101>
Trace; c8828db8 <[usb-ohci]hc_interrupt+d0/1d4>
Trace; c882c014 <[usb-ohci].data.end+20b5/4101>
Trace; c8829977 <[usb-ohci].rodata.start+257/72c>
Trace; c882c010 <[usb-ohci].data.end+20b1/4101>
Trace; c882c00c <[usb-ohci].data.end+20ad/4101>
Trace; c0109f1d <handle_IRQ_event+31/5c>
Trace; c010a087 <do_IRQ+6b/ac>
Trace; c0107160 <default_idle+0/28>
Trace; c0107160 <default_idle+0/28>
Trace; c0108e28 <ret_from_intr+0/20>
Trace; c0107160 <default_idle+0/28>
Trace; c0107160 <default_idle+0/28>
Trace; c0107183 <default_idle+23/28>
Trace; c01071e4 <cpu_idle+3c/50>
Trace; c0105000 <empty_bad_page+0/1000>
Trace; c0100192 <L6+0/2>
Code;  c8826a29 <[usb-ohci]sohci_free_dev+1e9/208>
00000000 <_EIP>:
Code;  c8826a29 <[usb-ohci]sohci_free_dev+1e9/208>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c8826a2b <[usb-ohci]sohci_free_dev+1eb/208>
   2:   83 c4 0c                  addl   $0xc,%esp
Code;  c8826a2e <[usb-ohci]sohci_free_dev+1ee/208>
   5:   89 f6                     movl   %esi,%esi
Code;  c8826a30 <[usb-ohci]sohci_free_dev+1f0/208>
   7:   8b 4c 24 14               movl   0x14(%esp,1),%ecx
Code;  c8826a34 <[usb-ohci]sohci_free_dev+1f4/208>
   b:   51                        pushl  %ecx
Code;  c8826a35 <[usb-ohci]sohci_free_dev+1f5/208>
   c:   e8 5a d9 8f f7            call   f78fd96b <_EIP+0xf78fd96b> c0124394 <kfree+0/c0>
Code;  c8826a3a <[usb-ohci]sohci_free_dev+1fa/208>
  11:   83 c4 04                  addl   $0x4,%esp

Kernel panic: Aiee, killing interrupt handler!


-----------------------------
/proc/modules:
-----------------------------

printer                 4960   0
usb-ohci               16496   0 (unused)
usbcore                47120   1 (autoclean) [printer usb-ohci]


-----------------------------
/proc/ksyms:
-----------------------------

c882ec80 __insmod_printer_S.rodata_L1086	[printer]
c882f0e0 __insmod_printer_S.data_L280	[printer]
c882f2e0 __insmod_printer_S.bss_L64	[printer]
c882e000 __insmod_printer_O/lib/modules/2.4.1/kernel/drivers/usb/printer.o_M3A775CC2_V132097	[printer]
c882e060 __insmod_printer_S.text_L3078	[printer]
c8829ea0 __insmod_usb-ohci_S.data_L192	[usb-ohci]
c8826060 __insmod_usb-ohci_S.text_L14010	[usb-ohci]
c8829720 __insmod_usb-ohci_S.rodata_L1905	[usb-ohci]
c8829eec sohci_device_operations	[usb-ohci]
c8826000 __insmod_usb-ohci_O/lib/modules/2.4.1/kernel/drivers/usb/usb-ohci.o_M3A775CC2_V132097	[usb-ohci]
c8819280 usb_ifnum_to_if	[usbcore]
c88192c0 usb_epnum_to_ep_desc	[usbcore]
c8819060 usb_register	[usbcore]
c8819210 usb_deregister	[usbcore]
c88190fc usb_scan_devices	[usbcore]
c8819634 usb_alloc_bus	[usbcore]
c88196a4 usb_free_bus	[usbcore]
c88196b8 usb_register_bus	[usbcore]
c8819778 usb_deregister_bus	[usbcore]
c8819d48 usb_alloc_dev	[usbcore]
c8819dd0 usb_free_dev	[usbcore]
c8819e00 usb_inc_dev_use	[usbcore]
c8819820 usb_driver_claim_interface	[usbcore]
c8819844 usb_interface_claimed	[usbcore]
c8819864 usb_driver_release_interface	[usbcore]
c8819884 usb_match_id	[usbcore]
c881aac0 usb_root_hub_string	[usbcore]
c881b8d8 usb_new_device	[usbcore]
c881d1fc usb_reset_device	[usbcore]
c881acc8 usb_connect	[usbcore]
c881abac usb_disconnect	[usbcore]
c8819504 usb_check_bandwidth	[usbcore]
c88195b8 usb_claim_bandwidth	[usbcore]
c88195f4 usb_release_bandwidth	[usbcore]
c881ae34 usb_set_address	[usbcore]
c881ae64 usb_get_descriptor	[usbcore]
c881af28 usb_get_class_descriptor	[usbcore]
c881ab40 __usb_get_extra_descriptor	[usbcore]
c881afd0 usb_get_device_descriptor	[usbcore]
c881af80 usb_get_string	[usbcore]
c881b78c usb_string	[usbcore]
c881b030 usb_get_protocol	[usbcore]
c881b07c usb_set_protocol	[usbcore]
c881b460 usb_get_report	[usbcore]
c881b4b8 usb_set_report	[usbcore]
c881b0b8 usb_set_idle	[usbcore]
c881b21c usb_clear_halt	[usbcore]
c881b2e4 usb_set_interface	[usbcore]
c881b508 usb_get_configuration	[usbcore]
c881b378 usb_set_configuration	[usbcore]
c881a1e8 usb_get_current_frame_number	[usbcore]
c8819e08 usb_alloc_urb	[usbcore]
c8819e64 usb_free_urb	[usbcore]
c8819e78 usb_submit_urb	[usbcore]
c8819ea8 usb_unlink_urb	[usbcore]
c881a0e8 usb_control_msg	[usbcore]
c881a180 usb_bulk_msg	[usbcore]
c8824800 usb_devfs_handle	[usbcore]
c8819000 __insmod_usbcore_O/lib/modules/2.4.1/kernel/drivers/usb/usbcore.o_M3A775CC2_V132097	[usbcore]
c8819060 __insmod_usbcore_S.text_L32672	[usbcore]
c88211e0 __insmod_usbcore_S.rodata_L11061	[usbcore]
c8824380 __insmod_usbcore_S.data_L1056	[usbcore]
c88247a0 __insmod_usbcore_S.bss_L100	[usbcore]
c01071f8 machine_real_restart
c02097c0 drive_info
c01d6140 boot_cpu_data
c02097a8 MCA_bus
c010f760 __verify_write
c01075cc dump_thread
c010dff8 dump_fpu
c010e0a0 dump_extended_fpu
c010ff5c __ioremap
c0110050 iounmap
c01a7810 __io_virt_debug
c0109f9c enable_irq
c0109f48 disable_irq
c010a6e8 disable_irq_nosync
c010a2e8 probe_irq_mask
c010742c kernel_thread
c02097a4 pm_idle
c0209390 pm_power_off
c010ce34 get_cmos_time
c02097e4 apm_info
c010022c gdt
c0107a9c __down_failed
c0107aa8 __down_failed_interruptible
c0107ab4 __down_failed_trylock
c0107ac0 __up_wakeup
c0107ae8 __down_write_failed
c0107acc __down_read_failed
c0107d10 __rwsem_wake
c01a7420 csum_partial_copy_generic
c01a758c __udelay
c01a7564 __delay
c01a75ac __const_udelay
c01a7768 __get_user_1
c01a777c __get_user_2
c01a7798 __get_user_4
c01a77b8 __put_user_1
c01a77cc __put_user_2
c01a77e8 __put_user_4
c01a79a0 strtok
c01a7968 strpbrk
c01a7b54 simple_strtol
c01a766c strncpy_from_user
c01a7648 __strncpy_from_user
c01a76bc clear_user
c01a7708 __clear_user
c01a760c __generic_copy_from_user
c01a75d0 __generic_copy_to_user
c01a772c strnlen_user
c010d610 pci_alloc_consistent
c010d680 pci_free_consistent
c010f2f0 pcibios_penalize_isa_irq
c02094c0 screen_info
c0107878 get_wchan
c01d65c8 rtc_lock
c01a7878 memcpy
c01a78a0 memset
c011814c dequeue_signal
c0117f20 flush_signals
c011881c force_sig
c01185d0 force_sig_info
c0118834 kill_pg
c0118658 kill_pg_info
c011887c kill_proc
c01194c8 kill_proc_info
c0118858 kill_sl
c01186ac kill_sl_info
c01189bc notify_parent
c0119510 recalc_sigpending
c01187f8 send_sig
c0118530 send_sig_info
c0117fd4 block_all_signals
c0118004 unblock_all_signals
c0119540 notifier_chain_register
c011956c notifier_chain_unregister
c01195a0 notifier_call_chain
c01195d8 register_reboot_notifier
c01195ec unregister_reboot_notifier
c011a54c in_group_p
c011a574 in_egroup_p
c01d6cc0 hotplug_path
c011aca0 exec_usermodehelper
c011b328 call_usermodehelper
c011b0fc request_module
c011b490 schedule_task
c011b698 flush_scheduled_tasks
c0112d30 inter_module_register
c0112e08 inter_module_unregister
c0112ea4 inter_module_get
c0112f04 inter_module_get_request
c0112f2c inter_module_put
c011374c try_inc_mod_count
c011d898 do_mmap_pgoff
c011e2dc do_munmap
c011e598 do_brk
c0114d9c exit_mm
c0114b28 exit_files
c0114c24 exit_fs
c0117f3c exit_sighand
c0126ef8 __alloc_pages
c0128eb0 alloc_pages_node
c01271e4 __get_free_pages
c0127204 get_zeroed_page
c0127234 __free_pages
c0127250 free_pages
c01d7100 contig_page_data
c020c498 num_physpages
c0124454 kmem_find_general_cachep
c0123a18 kmem_cache_create
c0123ecc kmem_cache_destroy
c0123e80 kmem_cache_shrink
c01241e0 kmem_cache_alloc
c01242dc kmem_cache_free
c0124238 kmalloc
c0124394 kfree
c01232bc vfree
c0123324 __vmalloc
c020c698 mem_map
c011cb2c remap_page_range
c020c680 max_mapnr
c020c478 high_memory
c011d150 vmtruncate
c011df68 find_vma
c011dcbc get_unmapped_area
c01d51e0 init_mm
c01249d8 deactivate_page
c01d8c60 def_blk_fops
c013edc8 update_atime
c012fa00 get_fs_type
c013051c get_super
c0130614 get_empty_super
c01354f0 getname
c020c6e8 names_cachep
c012c508 fput
c012c5d8 fget
c013ea94 igrab
c013ea28 iunique
c013eb04 iget4
c013ec38 iput
c013ed8c force_delete
c013583c follow_up
c01358cc follow_down
c01362ec path_init
c0135974 path_walk
c01356e8 path_release
c01364f4 __user_walk
c01364a4 lookup_one
c0136418 lookup_hash
c012b714 sys_close
c01d8f98 dcache_lock
c013d5fc d_alloc_root
c013d810 d_delete
c013cfc0 dget_locked
c013d740 d_validate
c013d878 d_rehash
c013cf64 d_invalidate
c013d8bc d_move
c013d5d0 d_instantiate
c013d470 d_alloc
c013d638 d_lookup
c013d9bc __d_path
c012d630 mark_buffer_dirty
c012d2a0 set_buffer_async_io
c012d604 __mark_buffer_dirty
c013de94 __mark_inode_dirty
c012c390 get_empty_filp
c012c498 init_private_file
c012b2d0 filp_open
c012b6b0 filp_close
c012c600 put_filp
c01d8a1c files_lock
c01329ac check_disk_change
c012ce94 __invalidate_buffers
c013e5c8 invalidate_inodes
c011eb68 invalidate_inode_pages
c011ed9c truncate_inode_pages
c012c968 fsync_dev
c013566c permission
c0135590 vfs_permission
c013ef44 inode_setattr
c013ee10 inode_change_ok
c013e26c write_inode_now
c013f060 notify_change
c012ce0c get_hardblocksize
c012cf68 set_blocksize
c012d474 getblk
c01326fc bdget
c01327c8 bdput
c012d764 bread
c012d6e4 __brelse
c012d704 __bforget
c015371c ll_rw_block
c0153660 submit_bh
c012c6e0 __wait_on_buffer
c011f45c ___wait_on_page
c012e8c8 block_write_full_page
c012e0a4 block_read_full_page
c012e620 block_prepare_write
c012f4f8 block_sync_page
c012e370 cont_prepare_write
c012e65c generic_commit_write
c012e6bc block_truncate_page
c012ea08 generic_block_bmap
c0120074 generic_file_read
c011fa9c do_generic_file_read
c01219fc generic_file_write
c0120af0 generic_file_mmap
c01d8920 generic_ro_fops
c011ef60 generic_buffer_fdatasync
c020c484 page_hash_bits
c020c48c page_hash_table
c01d8f88 file_lock_list
c013a9c8 locks_init_lock
c013aa6c locks_copy_lock
c013b680 posix_lock_file
c013b2ac posix_test_lock
c013c974 posix_block_lock
c013c988 posix_unblock_lock
c013b394 locks_mandatory_area
c013ce20 dput
c013d33c have_submounts
c013cfec d_find_alias
c013d03c d_prune_aliases
c013d0ac prune_dcache
c013d1f8 shrink_dcache_sb
c013d420 shrink_dcache_parent
c013dd1c find_inode_number
c013dc9c is_subdir
c012b47c get_unused_fd
c013654c vfs_create
c0136e88 vfs_mkdir
c0136c38 vfs_mknod
c0137548 vfs_symlink
c01376c4 vfs_link
c0137054 vfs_rmdir
c0137300 vfs_unlink
c0138024 vfs_rename
c012a2d0 vfs_statfs
c012b7a0 generic_read_dir
c01398c0 __pollwait
c0139870 poll_freewait
c020c6f0 ROOT_DEV
c011f638 __find_lock_page
c0121958 grab_cache_page
c01217a0 read_cache_page
c01382e0 vfs_readlink
c0138330 vfs_follow_link
c0138514 page_readlink
c0138560 page_follow_link
c01d8ee0 page_symlink_inode_operations
c012ef4c block_symlink
c01392a0 vfs_readdir
c013bbd0 __get_lease
c013bddc lease_get_mtime
c013cd10 lock_may_read
c013cd94 lock_may_write
c013931c dcache_readdir
c012b7a8 default_llseek
c012b32c dentry_open
c0120494 filemap_nopage
c01208c8 filemap_sync
c011f5b4 lock_page
c012c130 register_chrdev
c012c1b8 unregister_chrdev
c01328bc register_blkdev
c0132940 unregister_blkdev
c0156efc tty_register_driver
c0156fa4 tty_unregister_driver
c0217880 tty_std_termios
c01320a4 block_read
c0131b60 block_write
c0216680 blksize_size
c020cb00 hardsect_size
c0216a80 blk_size
c020d300 blk_dev
c0152ad8 is_read_only
c0152b14 set_device_ro
c013eda0 bmap
c012c944 sync_dev
c0146ddc devfs_register_partitions
c0132c04 blkdev_open
c0132ae0 blkdev_get
c0132c84 blkdev_put
c0132a40 ioctl_by_bdev
c020c6f4 gendisk_head
c0146e0c grok_partitions
c0146de0 register_disk
c01da68c tq_disk
c012d188 init_buffer
c012d6d4 refile_buffer
c020c700 max_sectors
c020cf00 max_readahead
c012c664 file_moveto
c0154ddc tty_hangup
c01593c0 tty_wait_until_sent
c0154a74 tty_check_change
c0154e00 tty_hung_up_p
c0156d0c tty_flip_buffer_push
c0156c8c tty_get_baud_rate
c0156af0 do_SAK
c01129c8 console_print
c01d69d0 console_loglevel
c012f7e0 register_filesystem
c012f824 unregister_filesystem
c0130d30 kern_mount
c0130da4 kern_umount
c0130dc0 may_umount
c0133640 register_binfmt
c013368c unregister_binfmt
c013436c search_binary_handler
c01340a8 prepare_binprm
c01341b4 compute_creds
c0134304 remove_arg_zero
c01346c8 set_binfmt
c0112294 register_exec_domain
c01122dc unregister_exec_domain
c0112314 __set_personality
c01168cc register_sysctl_table
c01168d0 unregister_sysctl_table
c011687c sysctl_string
c0116884 sysctl_intvec
c011688c sysctl_jiffies
c0116894 proc_dostring
c011689c proc_dointvec
c01168b4 proc_dointvec_jiffies
c01168ac proc_dointvec_minmax
c01168c4 proc_doulongvec_ms_jiffies_minmax
c01168bc proc_doulongvec_minmax
c0117198 add_timer
c011733c del_timer
c010a0c8 request_irq
c010a174 free_irq
c0209bc0 irq_stat
c0111190 add_wait_queue
c01111bc add_wait_queue_exclusive
c01111e4 remove_wait_queue
c010a1ec probe_irq_on
c010a354 probe_irq_off
c011726c mod_timer
c01d6ae4 tq_timer
c01d6aec tq_immediate
c013f624 kiobuf_init
c013f658 alloc_kiovec
c013f6b4 free_kiovec
c013f718 expand_kiobuf
c011c3fc map_user_kiobuf
c011c640 unmap_kiobuf
c011c6c4 lock_kiovec
c011c7a0 unlock_kiovec
c012eb64 brw_kiovec
c013f7b0 kiobuf_wait_for_io
c0111128 request_dma
c0111160 free_dma
c01d68a0 dma_spin_lock
c0107150 disable_hlt
c0107158 enable_hlt
c01165c8 request_resource
c01165e8 release_resource
c01166f4 allocate_resource
c01165f8 check_resource
c0116750 __request_region
c01167c8 __check_region
c0116808 __release_region
c01d6a94 ioport_resource
c01d6ab0 iomem_resource
c01151f4 up_and_exit
c01106a0 __wake_up
c0111090 wake_up_process
c0110888 sleep_on
c01108e0 sleep_on_timeout
c01107cc interruptible_sleep_on
c0110824 interruptible_sleep_on_timeout
c0110270 schedule
c01101cc schedule_timeout
c020ac6c jiffies
c0209c40 xtime
c010ca60 do_gettimeofday
c010cabc do_settimeofday
c01d5308 loops_per_jiffy
c020ac80 kstat
c020ac68 nr_running
c0112440 panic
c011282c printk
c01a8394 sprintf
c01a7fb8 vsprintf
c012c268 kdevname
c0132d78 bdevname
c012c294 cdevname
c01a7ab0 simple_strtoul
c01d5320 system_utsname
c01d6b80 uts_sem
c01d5518 sys_call_table
c01072a8 machine_restart
c0107314 machine_halt
c0107318 machine_power_off
c01e2dc0 _ctype
c015c84c secure_tcp_sequence_number
c015bf30 get_random_bytes
c01d6860 securebits
c01d6ad4 cap_bset
c011103c daemonize
c0133b1c setup_arg_pages
c01339bc copy_strings_kernel
c01344e0 do_execve
c0133e90 flush_old_exec
c0133d18 kernel_read
c0133c60 open_exec
c010f724 si_meminfo
c0209be0 sys_tz
c01303ec __wait_on_super
c012c9a8 file_fsync
c012d2ac fsync_inode_buffers
c013e3f8 clear_inode
c01d6fd4 nr_async_pages
c021ba6c ___strtok
c012c2d8 init_special_inode
c0216e80 read_ahead
c012cd7c get_hash_table
c013e844 get_empty_inode
c013ebd8 insert_inode_hash
c013ec24 remove_inode_hash
c012ce30 buffer_insert_inode_queue
c013f16c make_bad_inode
c013f19c is_bad_inode
c0209c50 event
c012eeb0 brw_page
c01d6b60 overflowuid
c01d6b64 overflowgid
c01d6b68 fs_overflowuid
c01d6b6c fs_overflowgid
c0138e68 fasync_helper
c0138f90 kill_fasync
c0146940 disk_name
c013569c get_write_access
c0112a44 register_console
c0112c88 unregister_console
c0115a98 get_fast_time
c01a78c0 strnicmp
c01a7930 strspn
c01a7a04 strsep
c0209c00 tasklet_hi_vec
c0209ae0 tasklet_vec
c0209840 bh_task_vec
c01163d4 init_bh
c01163f0 remove_bh
c01162ec tasklet_init
c0116310 tasklet_kill
c011641c __run_task_queue
c01e4000 init_task_union
c01f6520 tasklist_lock
c0209c60 pidhash
c011bcd0 pm_register
c011bd30 pm_unregister
c011bd54 pm_unregister_all
c011bd84 pm_send
c011be18 pm_send_all
c011be74 pm_find
c020ac60 pm_active
c01d9068 nfsd_linkage
c0143f14 proc_symlink
c014401c proc_mknod
c01440f4 proc_mkdir
c01441c0 create_proc_entry
c0144324 remove_proc_entry
c01d9160 proc_root
c020c6ac proc_root_fs
c020c6e4 proc_net
c020c6f8 proc_bus
c020c6a8 proc_root_driver
c014dcac register_nls
c014dcf8 unregister_nls
c014ddf8 unload_nls
c014dd80 load_nls
c014de88 load_nls_default
c014dae0 utf8_mbtowc
c014db6c utf8_mbstowcs
c014dbd0 utf8_wctomb
c014dc50 utf8_wcstombs
c01da694 io_request_lock
c01539a0 end_that_request_first
c0153a88 end_that_request_last
c0152980 blk_init_queue
c01526b0 blk_get_queue
c0153bac __blk_get_queue
c015272c blk_cleanup_queue
c0152784 blk_queue_headactive
c0152790 blk_queue_pluggable
c015279c blk_queue_make_request
c0153520 generic_make_request
c0153be4 blkdev_release_request
c01528a4 generic_unplug_device
c021727c queued_sectors
c01541a4 blk_ioctl
c0156ef4 tty_register_devfs
c0156ef8 tty_unregister_devfs
c015b384 misc_register
c015b460 misc_deregister
c015b9c8 add_keyboard_randomness
c015b9f0 add_mouse_randomness
c015ba04 add_interrupt_randomness
c015ba2c add_blkdev_randomness
c015b7b4 batch_entropy_store
c01db850 color_table
c01db860 default_red
c01db8a0 default_grn
c01db8e0 default_blu
c0218c60 video_font_height
c02177ac video_scan_lines
c0161000 vc_resize
c02177a8 fg_console
c021798c console_blank_hook
c02172a0 vt_cons
c0164724 take_over_console
c01648a0 give_up_console
c01653d0 set_selection
c0165988 paste_selection
c01697bc register_serial
c01699d4 unregister_serial
c0169b10 handle_scancode
c02178a8 kbd_ledfunc
c01df80c keyboard_tasklet
c016b620 autoirq_setup
c016b62c autoirq_report
c0218ca0 ide_hwifs
c016fe6c ide_register_module
c016fea8 ide_unregister_module
c016e8dc ide_spin_wait_hwgroup
c0218c88 ide_probe
c016bb14 drive_is_flashcard
c016d414 ide_timer_expiry
c016d6bc ide_intr
c01e195c ide_fops
c016d3d8 ide_get_queue
c016eae0 ide_add_generic_settings
c0218c84 ide_devfs_handle
c016d400 do_ide_request
c016fbc8 ide_scan_devices
c016fcfc ide_register_subdriver
c016fdf8 ide_unregister_subdriver
c016dcd4 ide_replace_subdriver
c016bca0 ide_input_data
c016bd58 ide_output_data
c016be08 atapi_input_bytes
c016be50 atapi_output_bytes
c016bef8 ide_set_handler
c016c5ac ide_dump_status
c016c900 ide_error
c016fa38 ide_fixstring
c016cc5c ide_wait_stat
c016c478 ide_do_reset
c016d868 ide_init_drive_cmd
c016d884 ide_do_drive_cmd
c016c488 ide_end_drive_cmd
c016be98 ide_end_request
c016d9a0 ide_revalidate_disk
c016ca90 ide_cmd
c016ece4 ide_wait_cmd
c016ed7c ide_wait_cmd_task
c016edb4 ide_delay_50ms
c016d0d0 ide_stall_queue
c0172788 ide_add_proc_entries
c01727ec ide_remove_proc_entries
c0172510 proc_ide_read_geometry
c01729ec create_proc_ide_interfaces
c016e660 ide_add_setting
c016e790 ide_remove_setting
c016e488 ide_register_hw
c016e604 ide_register
c016de7c ide_unregister
c016e418 ide_setup_ports
c016dd6c hwif_unregister
c016d7fc get_info_ptr
c016bf5c current_capacity
c016edd0 system_bus_clock
c017007c ide_auto_reduce_xfer
c0170184 ide_driveid_update
c01702f4 ide_ata66_check
c0170354 set_transfer
c0170394 eighty_ninty_three
c01703d0 ide_config_drive_speed
c0175f2c register_sound_special
c0175fe4 register_sound_mixer
c0176010 register_sound_midi
c017603c register_sound_dsp
c0176068 register_sound_synth
c0176094 unregister_sound_special
c01760b0 unregister_sound_mixer
c01760c4 unregister_sound_midi
c01760d8 unregister_sound_dsp
c01760ec unregister_sound_synth
c0176424 mod_firmware_load
c0176c64 pci_read_config_byte
c0176c8c pci_read_config_word
c0176cc4 pci_read_config_dword
c0176cf8 pci_write_config_byte
c0176d24 pci_write_config_word
c0176d64 pci_write_config_dword
c01e1ba8 pci_devices
c01e1ba0 pci_root_buses
c0176820 pci_enable_device
c017654c pci_find_capability
c017651c pci_find_class
c0176500 pci_find_device
c0176450 pci_find_slot
c0176490 pci_find_subsys
c0176d98 pci_set_master
c0176694 pci_set_power_state
c0177684 pci_assign_resource
c017696c pci_register_driver
c01769cc pci_unregister_driver
c0176c30 pci_dev_driver
c01768a8 pci_match_device
c0176618 pci_find_parent_resource
c017703c pci_setup_device
c0176b38 pci_insert_device
c0176be0 pci_remove_device
c0177380 pcibios_present
c0177454 pcibios_read_config_byte
c0177490 pcibios_read_config_word
c01774cc pcibios_read_config_dword
c0177508 pcibios_write_config_byte
c0177550 pcibios_write_config_word
c0177598 pcibios_write_config_dword
c0177394 pcibios_find_class
c01773ec pcibios_find_device
c021ab44 isa_dma_bridge_buggy
c021ab40 pci_pci_problems
c017bf20 skb_over_panic
c017bf68 skb_under_panic
c017acf4 sock_register
c017ad34 sock_unregister
c017b988 __lock_sock
c017ba1c __release_sock
c017c830 memcpy_fromiovec
c017c7d4 memcpy_tokerneliovec
c0179dc8 sock_create
c0179674 sock_alloc
c017972c sock_release
c017ae70 sock_setsockopt
c017b258 sock_getsockopt
c017977c sock_sendmsg
c0179820 sock_recvmsg
c017b5d8 sk_alloc
c017b62c sk_free
c0179d58 sock_wake_async
c017b86c sock_alloc_send_skb
c017bdf0 sock_init_data
c017bbc8 sock_no_release
c017bbcc sock_no_bind
c017bbd4 sock_no_connect
c017bbdc sock_no_socketpair
c017bbe4 sock_no_accept
c017bbec sock_no_getname
c017bbf4 sock_no_poll
c017bbf8 sock_no_ioctl
c017bc00 sock_no_listen
c017bc08 sock_no_shutdown
c017bc18 sock_no_getsockopt
c017bc10 sock_no_setsockopt
c017bc88 sock_no_sendmsg
c017bc90 sock_no_recvmsg
c017bc98 sock_no_mmap
c017b69c sock_rfree
c017b66c sock_wfree
c017b6ac sock_wmalloc
c017b6fc sock_rmalloc
c017cc08 skb_recv_datagram
c017cce0 skb_free_datagram
c017cd00 skb_copy_datagram
c017cd34 skb_copy_datagram_iovec
c017c498 skb_copy_expand
c017cd54 datagram_poll
c017d0cc put_cmsg
c017b744 sock_kmalloc
c017b780 sock_kfree_s
c0180d4c neigh_table_init
c0180e40 neigh_table_clear
c01808a4 neigh_resolve_output
c01809fc neigh_connected_output
c01803ec neigh_update
c017fac4 neigh_create
c017fa58 neigh_lookup
c0180298 __neigh_event_send
c01806cc neigh_event_ns
c017f81c neigh_ifdown
c017fc18 pneigh_lookup
c0180b90 pneigh_enqueue
c017fe30 neigh_destroy
c0180c60 neigh_parms_alloc
c0180cf4 neigh_parms_release
c017f6c8 neigh_rand_reach_time
c0180840 neigh_compat_output
c017f430 dst_alloc
c017f4a8 __dst_free
c017f530 dst_destroy
c0180f90 net_ratelimit
c0180f60 net_random
c0180f80 net_srandom
c017cef0 __scm_destroy
c017cf28 __scm_send
c017d3c4 scm_fp_dup
c01d8a00 files_stat
c017c634 memcpy_toiovec
c01a7338 csum_partial
c017bae8 sklist_destroy_socket
c017bab8 sklist_insert_socket
c017d19c scm_detach_fds
c01e2a54 inetdev_lock
c0184a30 inet_add_protocol
c0184a80 inet_del_protocol
c0183fe8 ip_route_output_key
c0183878 ip_route_input
c019e298 icmp_send
c019e0e4 icmp_reply
c0186104 ip_options_compile
c01866bc ip_options_undo
c019d0e4 arp_send
c01e25a0 arp_broken_ops
c0182444 __ip_select_ident
c018804c ip_send_check
c0187b58 ip_fragment
c01e2b00 inet_family_ops
c0181a50 in_aton
c01a0bf8 ip_mc_inc_group
c01a0cb8 ip_mc_dec_group
c0188094 ip_finish_output
c01e2ac0 inet_dgram_ops
c0188274 ip_cmsg_recv
c01a137c inet_addr_type
c019f788 inet_select_addr
c01a1300 ip_dev_find
c019f070 inetdev_by_index
c019eafc in_dev_finish_destroy
c018581c ip_defrag
c01a1618 ip_rt_ioctl
c019f108 devinet_ioctl
c019f844 register_inetaddr_notifier
c019f858 unregister_inetaddr_notifier
c021ada0 ip_statistics
c017e46c dev_set_allmulti
c017e40c dev_set_promiscuity
c017ba68 sklist_remove_socket
c01e1e50 rtnl_sem
c0180ec0 rtnl_lock
c0180ed4 rtnl_unlock
c021ac04 ipv4_config
c017d8bc dev_open
c0181a20 in_ntoa
c0184d4c ip_rcv
c019d2fc arp_rcv
c01e25c0 arp_tbl
c019cf38 arp_find
c017d9c8 register_netdevice_notifier
c017d9dc unregister_netdevice_notifier
c016b34c init_etherdev
c01e1660 loopback_dev
c017eb48 register_netdevice
c017ed88 unregister_netdevice
c016b4a8 register_netdev
c016b528 unregister_netdev
c017d828 netdev_state_change
c016b3c8 ether_setup
c017eb10 dev_new_index
c017d6e0 dev_get_by_index
c017d6c0 __dev_get_by_index
c017d690 dev_get_by_name
c017d650 __dev_get_by_name
c017ece8 netdev_finish_unregister
c017e374 netdev_set_master
c0181160 eth_type_trans
c017bfb0 alloc_skb
c017c194 __kfree_skb
c017c284 skb_clone
c017c3ec skb_copy
c017dc34 netif_rx
c017d410 dev_add_pack
c017d45c dev_remove_pack
c017d6a8 dev_get
c017d7c4 dev_alloc
c017d774 dev_alloc_name
c01814c0 __netdev_watchdog_up
c017d844 dev_load
c017e89c dev_ioctl
c017daac dev_queue_xmit
c01e1790 dev_base
c01e1794 dev_base_lock
c017d95c dev_close
c017f0cc dev_mc_add
c017f020 dev_mc_delete
c017f004 dev_mc_upload
c01599c0 n_tty_ioctl
c015481c tty_register_ldisc
c0138f30 __kill_fasync
c01e1ddc if_port_text
c0181844 qdisc_destroy
c018182c qdisc_reset
c0181330 qdisc_restart
c0181770 qdisc_create_dflt
c01e1ee0 noop_qdisc
c01e1e80 qdisc_tree_lock
c017e00c register_gifconf
c017de04 net_call_rx_atomic
c021ae60 softnet_data
c01a8448 memparse
c01a83b0 get_option
c01a83fc get_options


------------------------------------------

Re: Bug report

[Jens Axboe]

On Thu, Feb 01 2001, Anders S. Buch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> It seems that the ide/cdrom/amd756 code can cause some bad lockups, at
> least on my system.  I have an Athlon 500 system running the 2.4.1 kernel
> with Redhat 6.1 + updated modutils, etc.

Have you tried disabling DMA on the atapi drive, not all do atapi
dma in an orderly fashion (yet)?

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Bug report

[Alexander Larsson]

In the embedded 2.2.5 sources i found the following in
arch/ppc/kernel/ppc-stub.c


static inline void set_msr(int msr)
{
	asm volatile("mfmsr %0" : : "r" (msr));
}

Shouldn't that be mtmsr?

/ Alex


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Bug report

[Dan Malek]

Alexander Larsson wrote:

> 
> In the embedded 2.2.5 sources i found the following in
> arch/ppc/kernel/ppc-stub.c
> 
> static inline void set_msr(int msr)
> {
>         asm volatile("mfmsr %0" : : "r" (msr));
> }
> 
> Shouldn't that be mtmsr?

Yes....Fortunately, it is only used in the kgbd portion of the
kernel, so normal operations are not affected.


	-- Dan

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]